TTL, Invalidation & Consistency

PriceMart drops prices in a flash sale. Watch a cached price go stale and a customer hit the old price at checkout — then fix it with a short TTL, delete-on-write, or event-based invalidation. Live TTL countdown bars make 'caching is easy, invalidation is hard' obvious.

PriceMart starts a flash sale. Drop the price and watch the product page (reads cache) disagree with checkout(reads the database) — then change the invalidation strategy and watch the gap shrink or vanish.

🛍️ Product page · reads cache

₹4,999

TTL: 10s left

💳 Checkout · reads DB (truth)

₹4,999

always the source of truth

✓ Page and checkout agree — the cache is consistent with the source of truth.

Cache events

// drop the price to see what the cache does

With TTL 10s, drop the price and the page stays wrong for up to 10 seconds. Switch to event-based and the page corrects instantly — that's the cost/freshness dial.

What just happened

▹TTL (time-to-live) is the simplest invalidation: cached data is trusted for N seconds, then refetched. Short TTL = fresher but more origin load; long TTL = faster but more stale-data risk.
▹Between a write and the next refresh, the cache serves the OLD value. On a product page that means the customer sees one price and checkout (reading the source of truth) shows another — the classic flash-sale complaint.
▹Stronger invalidation closes that gap: delete-on-write removes the entry so the next read repopulates fresh, and event-based invalidation updates the cache the moment the data changes. 'Caching is easy; correct invalidation is hard.'