ON THIS PAGE (7 SECTIONS)
- ✓RFC 9111 defines HTTP caching, including freshness and revalidation. Application caches need the same honesty about age.
- ✓The hard part is not storing the copy. It is knowing when the copy is no longer acceptable.
- ✓Cache keys must include every input that changes the result, including the tenant and the permission.
- ✓A cache of model responses is a product decision about staleness, separate from token budgets.
A product page is slow, so the JSON is cached for an hour. A price change takes effect in the database and not on the page. Support hears about it from a customer. The cache did what it was configured to do. Nobody had written down that a price may not be an hour old.
RFC 9111 describes how HTTP caches store responses and reuse them while they are fresh, and how they revalidate when they are not. The same decision exists if you use Redis or memory instead of HTTP. You are serving a copy. Say how old it may be, and say what event makes it unusable. "We will clear it manually" is not an event. It is a hope.
What is reasonable to copy
| Data | A cache can be honest when | Do not cache as if it were fresh |
| Public catalog text | A delay of minutes is acceptable and a write purges the key | The price is regulated or shown at checkout |
| A user profile the user just edited | The write deletes that user’s key | You wait for a timer while the user stares at the old name |
| A permission or a tenant boundary | The key includes the tenant and the user, and a revocation deletes it | You cache "allowed" across users |
| An account balance or a stock count | You do not. Read the source. | You serve a number someone will act on |
| A model completion | The inputs are identical and a stale answer is acceptable | The source document may have changed. See retrieval freshness |
Key design is part of correctness. A key of only the URL, shared across tenants, is a leak. A key that omits a query parameter will serve one customer’s filter to another. Include every input. Separate Tenant Data Before You Share a Store applies to the cache as much as to the table. Token-level cost caching for models is a different article, Controlling Enterprise AI Costs. This one is about whether the copy is still true enough.
Illustrative scenario
This scenario is illustrative. Product descriptions are cached for five minutes and also deleted when an editor publishes. Prices are read from the pricing service at add-to-cart and are not taken from the page cache. The page can be slightly behind the prose. The charge cannot be behind the price. A test updates a description and asserts the next read misses the cache. A test for price never looks at the cache, because there is not one.
Checklist
- For each cached value, write the maximum age you will defend to a user.
- Delete or version the key on the write that changes the source.
- Put tenant, user, and every parameter in the key.
- Do not cache balances, inventory you will sell, or authorization across people.
- Measure the hit rate. A cache that never hits is complexity. A cache that hits forever is stale.
- Plan for the cache being empty. The source must still be able to serve.
Questions that usually come next
Is a short TTL a substitute for invalidation?
It is a bound on staleness, which is useful. It does not make a write visible now. If the user just saved the value, delete the key. Use the TTL for everything else.
Should we cache at the CDN and in the application?
Yes, if both honor the same rule. A CDN that caches a private response because a header was missing is a new copy you forgot. Private and public data should not share a cache policy.
Direct answers
Is a short TTL enough?
It limits how stale a value can get. It does not refresh a value the user just changed. Delete that key on write.
Can the CDN and the app both cache?
Yes, if private responses stay private in both. One missed header creates a public copy of a private page.
References & Prior Art
RFC 9111: HTTP Caching
R. Fielding, M. Nottingham, J. Reschke • IETF (2022)
Naveen
Infrastructure EngineerNaveen handles infrastructure, edge network resilience, chunked media pipelines, and deterministic CI/CD release verification at Vasiva.
