Caching Fundamentals: Cache‑Aside, Eviction, and TTL
Use the cache‑aside pattern: check Redis, on miss fetch DB and set TTL, invalidate on writes.
Implement cache‑aside with Redis, set appropriate TTLs, and delete cache entries on updates.
Summary
Caching is essential for read‑heavy, write‑light workloads, reducing database load by serving repeated requests from memory. The cache‑aside pattern, the most widely used approach, involves checking the cache first, fetching from the database on a miss, storing the result with a TTL, and invalidating on writes by deleting the key rather than updating to avoid race conditions. Eviction policies such as LRU or LFU determine which entries are removed when memory limits are reached, while TTLs balance freshness against performance.
Distributed caches like Redis or Memcached provide sub‑millisecond access across multiple instances, whereas in‑process caches offer the fastest access but are not shared. CDN edge caches further reduce latency for static assets. Proper cache design ensures that the application remains functional even if the cache fails, as the system falls back to the database.
Key concepts include read/write flows, TTL management, cache stampede prevention, and the trade‑off between speed and data freshness.
Key changes
- Read flow: check cache, on miss query DB and set TTL
- Write flow: delete cache entry to avoid race conditions
- TTL controls data freshness and cache size
- Distributed cache (Redis/Memcached) shares data across instances
- In‑process cache offers fastest access but is not shared
- Cache stampede can be mitigated with locking or request coalescing