5
System Design
Caching vs real-time reads for stock availability on product pages
Performance ↔ Freshness
Context
Show stock availability on product pages at 30K reads/sec.
Product pages show "In stock / Only 3 left / Sold out". Reads peak at 30K/sec; stock changes about 200/sec, spiking during flash sales.
Option A: cache availability in Redis with a short TTL, and invalidate on stock-change events from Kafka.
Option B: read real time from the inventory service on every page view.
The business rule that matters: we must never oversell. Does that force real-time reads?
Constraints
- Read load
- ~30K reads/sec at peak
- Stock updates
- ~200/sec, bursty during sales
- Rule
- Never oversell at checkout
Cache with short TTL + event invalidationvsRead real-time from the inventory service
Community verdict
Cache with short TTL + event invalidation 70%Read real-time from the inventory service 30%
10 engineers · 5 opinions
With these constraints, what would you choose?
One choice per engineer. You can change it any time.
Cache with short TTL + event invalidation
Read real-time from the inventory service
Freshness →
Trade-offs
Dimensions
Cache with short TTL + event invalidationRead real-time from the inventory serviceout of 5
- Latency
- 5Cache with short TTL + event invalidation scores 5 of 52Read real-time from the inventory service scores 2 of 5
- Freshness
- 3Cache with short TTL + event invalidation scores 3 of 55Read real-time from the inventory service scores 5 of 5
- Load on source
Community discussion
5 comments
Have you made this decision in production? Share your reasoning.
Sign in to commentWatch the stampede: when a hot key expires, hundreds of requests hit inventory at once. Request coalescing or early refresh solved it for us.
During flash sales the cache is wrong precisely when it matters. We showed "available" on items that sold out in 4 seconds and support hated us. Real-time with a read replica held up fine at our scale.
Then shorten the TTL during sales, or push updates for hot SKUs. One rule for the whole catalogue is the mistake.
"Never oversell" is a checkout rule, not a product-page rule. Reserve stock transactionally at checkout against the source of truth; the product page can be a few seconds stale.
Showing "in stock" for 2 seconds after the last unit sold is a UX blemish. Overselling is a refund and an angry customer. Put the strong consistency where the money moves.
Exactly where we landed: cached browse path, authoritative reservation path.