Caching is the cheapest speed you'll ever buy — and the fastest way to ship subtle, maddening bugs if you do it carelessly. The famous joke that "there are only two hard problems in computer science: cache invalidation and naming things" exists for a reason. Done well, caching cuts latency and load dramatically. Done badly, it serves stale data to users and erodes their trust. Here's how to layer it deliberately.
Cache at the right layer
A request passes through several places where you can cache, each catching a different kind of work:
-
Client / browser cache. HTTP caching headers (
Cache-Control\,ETag\) let the browser skip requests entirely for static assets. Free and enormously effective. - CDN cache. A CDN serves cached responses from the edge, close to users. Ideal for static files and cacheable API responses.
- Application cache. An in-memory store like Redis holds computed results, session data, and hot database rows so you don't recompute or refetch them.
- Database cache. Query result caching and materialized views cut repeated expensive queries.
The best strategy usually combines several layers. A request that never reaches your server is faster and cheaper than one you serve quickly.
Pick a pattern that matches your data
For application caching, the most common and reliable pattern is cache-aside: on a read, check the cache first; on a miss, load from the database, store it in the cache, then return it. It's simple and puts you in control of what's cached and for how long.
Set a TTL (time to live) on entries so even if invalidation logic has a gap, stale data expires on its own. A short TTL is a safety net — it bounds how wrong the cache can be.
Invalidation is the hard part — plan for it
Stale data is the cost of caching, and the whole craft is managing it. A few tactics that keep you out of trouble:
- Prefer expiry over cleverness. A short TTL is often simpler and safer than intricate invalidation logic, and it fails gracefully.
- Invalidate on write. When data changes, evict or update the relevant cache key in the same operation.
- Namespace and version your keys so you can invalidate a whole category at once and avoid collisions.
Ask a blunt question for each cached value: how wrong can this be, and for how long, before a user is harmed? A product catalog can be seconds stale; an account balance cannot. Let that answer set your TTLs.
Don't cache what you don't need to
Caching adds a moving part, and moving parts break. Before adding a cache, confirm you actually have a hot path worth optimizing — measure first. Sometimes the right fix is an index or a better query, not another layer to keep in sync. Never cache highly personalized or security-sensitive data at a shared layer like a CDN, where one user could receive another's response.
Layer up gradually
Start with the cheap wins: proper HTTP caching headers and a CDN for static assets. Add Redis for genuinely expensive computations and hot data as load grows. Introduce each layer only when you can point to the metric it improves. Caching should be a scalpel you apply to measured bottlenecks — not a blanket you throw over the whole app and hope.
If your app is slow and you're not sure which layer to cache, talk to us.
Originally published on the Doktouri Agency blog. We build web, mobile, SaaS, and AI products — let's talk.
Top comments (0)