RESULT CACHE · KEYS AND LIFETIMES
Application result caching: reuse without changing the answer
Eight questions from five users hit an answer cache while a price changes; see which cache keys and lifetimes change the answers people get.
Your experiment
Five users ask the same two questions over 25 minutes; one asks in German, two ask about their own orders, and the reading-lamp bundle price changes at minute 10. A cached answer is correct only if it equals what a fresh model call would say. Start with a text-only key, then add locale, the data version and per-user scoping, and vary the lifetime.
Play replays the computed run over sixty inspection seconds; Next event steps, Restart rewinds, Speed changes the pace and Inspection time scrubs. Any input change recomputes the run and rewinds it without autoplay.
Event trace
Computed data
Final metrics
Deterministic fixture: the “model” always gives the correct answer for the user, locale and current price, so every difference is caused by the cache. Lifetime 0 disables caching. Real caches also need size limits, eviction and protection against caching errors; semantic (meaning-based) caches add a similarity threshold that this page does not model.
A cache must not change the answer
Five users ask two questions over 25 minutes. A cached answer is correct only if it equals what a fresh model call would say. With the opening key, the question text alone, and a 30-minute lifetime, 6 of 8 requests hit the cache and 5 answers are wrong: Geetha, who uses German, gets the English answer; Tanishka asks where an order is and is told about Jenya’s order; and after the price changes at minute 10, Dinky, Hansini and Geetha still get the old ₹300. The hit rate looks excellent: CACHE CHANGED ANSWERS.
Everything that changes the answer belongs in the key
Set Cache key to Question text + locale: Geetha gets the German answer, but 4 answers are still wrong. Question text + locale + price-data version ends the stale prices because a new data version is a new key, leaving 3 hits and 1 wrong answer: Tanishka still receives Jenya’s order. The key has to include every input the answer depends on, including data versions, not only the words of the question.
Personal answers
Personal questions decides how “Where is my order?” is cached. Cached per user puts the user in the key, and Never cached skips it; with either, plus the versioned key, the cache serves 2 of 8 requests and every answer is right: REUSE IS SAFE. A shared cache that ignores identity turns a performance feature into a data leak.
Lifetimes trade hits for staleness
Cache lifetime 0 turns caching off: 0 hits, no wrong answers. With the text-only key, 5 minutes still lets Geetha and Tanishka receive wrong answers, but no longer the stale price: 3 hits and 2 wrong. With locale and per-user keys, 5 minutes is safe with 1 hit. 60 minutes behaves like 30 here. A short lifetime reduces staleness only when nothing else is wrong with the key; invalidation by data version is more precise than waiting.
Reading the run and its limits
Play, Next event, Restart, Speed and Inspection time step through every request and the price change across sixty seconds; the table lists cache hits, the answer served and why it is wrong. The fixture model always answers correctly, so every error comes from the cache. Real caches also need size limits, eviction and care not to cache errors; meaning-based caches add a similarity threshold this page does not model.