Concept
Five Core Benefits & Cache Topology
Why Cache?
A well-implemented cache can reduce database load by orders of magnitude, cut latency from hundreds of milliseconds to microseconds, and absorb traffic spikes that would otherwise cause outages.
Five core benefits:
- Reduced latency — In-memory caches (Redis, Memcached) respond in microseconds; database queries take tens of milliseconds.
- Reduced backend load — If 90% of reads hit the cache, your database handles 10% of its previous read volume.
- Increased throughput — Redis handles 100k–1M QPS versus a single database's 10–25k read QPS.
- Traffic spike absorption — A viral article or flash sale overwhelms a database, not a cache.
- Improved availability — A cache can serve stale data during transient database failures.
Where to Place the Cache
| Layer | Technology | Best For |
|---|---|---|
| Client-side | Browser / HTTP headers | Static assets, user preferences |
| CDN | Cloudflare, Fastly, CloudFront | Static files, public API responses |
| In-process | Local memory on app server | Small, rarely changing data; not shared across instances |
| Distributed cache | Redis, Memcached | The standard production pattern — shared across all app servers |
Cache-Aside (Lazy Loading) — The Default Pattern
On a read miss, the application fetches from the database and populates the cache. On a write, it updates the database and deletes the cache entry (not updates — to avoid race conditions from concurrent writes). This is the correct default for most systems.