Sample output
Made on 27 October 2026
Caching Strategy
1. Data Classes
| Data class | Cache layer | TTL and reasoning | Invalidation trigger | Staleness tolerance |
|---|---|---|---|---|
| Product content: name, description, images, category, attributes | CDN + distributed cache + app-local cache | CDN: 15–60 min; distributed: 30 min; app-local: 1–5 min. This data changes infrequently and benefits most from edge caching. | Product update event; purge affected product, category, search, and listing keys. | 15–60 min for presentation data; near-zero for legal or compliance fields. |
| Price | Distributed cache; CDN only with short TTL and explicit business approval | 5–10 min, despite hourly updates. This limits stale-price exposure while absorbing read traffic. App-local TTL: 30–60 sec. | Price-change event immediately deletes or updates the product/SKU price key. Scheduled refresh after hourly price imports. | Prefer under 1 min after an update event; hard maximum 5–10 min. Checkout must revalidate against the pricing source. |
| Stock availability | Distributed cache with very short TTL; optional app-local microcache | Distributed: 1–5 sec; app-local: 250 ms–1 sec. Stock changes too frequently for long-lived caching, but a microcache can collapse bursts. | Inventory reservation, release, receipt, adjustment, or sale event updates/deletes the SKU inventory key. | 1–5 sec for browsing. Cart and checkout must perform authoritative availability/reservation checks. |
| Product detail response | CDN for public, non-personalized fragments; distributed cache for assembled responses | 30–60 sec if price and stock are excluded or fetched separately. If included, TTL must match the shortest-lived component, typically 1–5 sec. | Any component update. Prefer fragment caching to avoid broad invalidations. | Depends on fields; do not let stable metadata inherit stock’s strict freshness requirement. |
| Category/listing pages | CDN + distributed cache | CDN: 30–120 sec; distributed: 1–5 min. Lists are expensive |