Cache Coherency Strategies: Cache Aside, Read Through, Write Through, and Write Back

Cache coherency determines how data stays synchronized between the cache layer and the source of truth (usually a database). The four main patterns make different tradeoffs between consistency, latency, and complexity. Cache aside, the most common pattern, puts the application in control: on a read miss, the app fetches from the database and populates the cache; on writes, the app writes to the database first and then invalidates or updates the cache entry. This gives the app flexibility and keeps the cache simple, but creates a window where readers might see stale data between the database write and the cache invalidation. Combining cache aside with short TTLs (time to live) provides a safety net, automatically expiring stale entries after seconds or minutes even if invalidation fails. Read through and write through move responsibility into the cache layer itself. In read through, the cache intercepts all read requests and automatically fetches from the database on misses, transparently loading and returning the value. This centralizes miss handling and enables request coalescing, where multiple concurrent requests for the same missing key are collapsed into one backend query. Write through means all writes go through the cache to the database synchronously before acknowledging success, so the cache is always consistent with the database. This reduces staleness windows but adds write latency because every write must complete a round trip to persistent storage. Write back (also called write behind) is the most aggressive: writes are acknowledged as soon as they reach the cache, and the cache asynchronously drains them to the database in the background. This minimizes write latency but risks data loss if a cache node crashes before flushing its write buffer. Production systems often combine these patterns. Meta memcache uses cache aside with lease based refill to prevent dogpiles: when a popular key expires, the cache returns a lease token to one requester granting exclusive rights to refresh the value, while other concurrent requests receive stale data or wait briefly. Netflix EVCache uses cache aside with very short TTLs and serves stale data on failures to preserve availability. AWS DAX uses write through and read through to maintain strong API semantics with DynamoDB while accelerating reads to microseconds. The choice depends on the consistency requirements and read write ratio of the workload: read heavy systems with tolerance for seconds of staleness prefer cache aside; write heavy systems needing read after write consistency prefer write through; and systems with bursty writes and idempotent or derivable data can use write back with replicated write buffers.

Meta memcache cache aside with leases: when a popular user profile key expires, thousands of requests arrive simultaneously. The cache grants one lease token to refresh from MySQL while others receive the stale value, preventing a dogpile that could generate 10,000 plus simultaneous database queries.

AWS DynamoDB Accelerator (DAX) write through: applications write to DAX, which synchronously commits to DynamoDB before responding. This maintains strong consistency semantics of the DynamoDB API while accelerating subsequent reads from microseconds instead of milliseconds.

A session store using write back: user session updates are acknowledged in microseconds by writing to an in memory cache with a replicated write buffer, then asynchronously flushed to a persistent database every 5 seconds. Session data is reconstructable from login events if lost, making the data loss risk acceptable.