Caching

Cache-aside (lazy loading) puts your application in control: check the cache first, and only hit the database on a miss, then populate the cache for next time.

Write-through caching synchronously writes data to both cache and database before confirming success to the application. This pattern guarantees strong consiste

Write-behind (also called write-back) is a caching pattern where writes go to cache first and are asynchronously propagated to the database later, dramatically

Refresh-ahead is a proactive caching pattern that automatically refreshes cache entries before they expire, based on predictions about which items will be acces

Client caching stores resources directly in the user's browser or device, eliminating network requests for repeated content. HTTP cache headers (Cache-Control,

CDN caching serves static assets from edge nodes closest to users. Learn cache-control headers, TTL strategies, cache invalidation, and CDN vs origin tradeoffs.

Web server caching places a reverse proxy (Nginx, Varnish, Apache Traffic Server) between clients and application servers to cache HTTP responses. This reduces

Database caching layers — query cache, buffer pool, and Redis — reduce disk I/O dramatically. Learn when to cache at DB vs app layer and common invalidation pitfalls.

Application caching uses in-memory data stores (like Redis or Memcached) positioned between your application servers and databases to dramatically reduce latenc

Cache eviction decides what to remove when memory is full. Compare LRU, LFU, FIFO, and ARC policies with use cases, hit rate tradeoffs, and interview-ready examples.

Cache invalidation is the process of removing or updating stale data from a cache to maintain consistency with the source of truth. It's famously one of the har

Read-through caching moves cache management logic from application code into the cache library itself. When your application requests data, the cache library au