INTRO
Caching fixes the wrong problem if the underlying query is O(n²). But once queries are sane, caching is the cheapest win. I treat HTTP caches (browser + CDN) and application caches (Redis) as different tools with different invalidation stories.
HTTP layer: public vs private
Immutable assets get long `max-age` and fingerprinted filenames. Personalized JSON usually needs `private, no-store` unless you segment by cookie carefully.
`stale-while-revalidate` helps marketing pages; APIs rarely want surprises.
Redis layer: explicit TTL and busting
Cache denormalized read models with TTL as safety net. For stronger consistency, delete keys on write (write-through / cache aside).
Name keys with version prefixes when schema changes: `v2:product:123`.
Cache stampede mitigation
When a hot key expires, many workers may refetch at once. Single-flight (one recomputes, others wait) or probabilistic early expiration reduces spikes.
KEY TAKEAWAYS
“Use HTTP caches for static and semi-static assets.”
- 02
Use Redis when you need cross-request sharing and invalidation logic.
- 03
Always plan stampede behavior for hot keys.
CONCLUSION
Closing thought
Caching is policy: who can see stale data, for how long, and how writes propagate. Document that per resource. Ready to talk scope? Use Contact — or browse Services for fit.
CONTINUE
Related pages
UP NEXT
Idempotency and Webhook Reliability for Payment Flows
How to design payment APIs that survive retries and out-of-order webhooks: idempotency keys, event deduplication, and state transitions with auditability.
Read next article