Caching & Redis Strategy
To minimize database load, the pricing engine uses Redis to cache rates, regions, and platform fee configurations. This document details the cache keys, TTL (Time-To-Live) strategies, and invalidation rules.
🗃️ Caching Architecture
🔑 Cache Configuration Keys & TTLs
| Cache Key | Data Type | TTL | Description |
|---|---|---|---|
pricing:rates:<category> | JSON String | 1 Hour (3,600s) | Mapped pricing rates for the selected category. |
pricing:regions:map | JSON String | 6 Hours (21,600s) | Mapped region groups and country codes. |
pricing:tiers:<category> | JSON String | 1 Hour (3,600s) | Active volume discount tiers for the selected category. |
pricing:fees:vendor:<vendorId> | JSON String | 1 Hour (3,600s) | Custom platform fee rule override for the vendor. |
pricing:fees:default | JSON String | 1 Hour (3,600s) | Global default platform fee rule. |
🔄 Cache Eviction & Invalidation Strategy
To prevent outdated pricing data from being served, the cache is invalidated when configuration tables are updated:
1. Programmatic Invalidation
When an administrator modifies rates, regions, tiers, or fee rules via the admin panel, the system invalidates the corresponding cache keys:
- Adding / Modifying Rates: Evicts
pricing:rates:*keys. - Modifying Regions: Evicts
pricing:regions:map. - Modifying Platform Fees: Evicts
pricing:fees:defaultorpricing:fees:vendor:<vendorId>(for vendor-specific overrides).
2. Auto-Recovery
If Redis experiences an outage or eviction pressure:
- Caching logic degrades gracefully to read directly from PostgreSQL without failing the estimation request.
- The cache is automatically populated on the next successful database read.