In caching, compare the cache-aside, write-through, and write-behind (write-back) strategies for keeping a cache and its backing database in sync: describe how each handles reads and writes, and the consistency/durability trade-off of each.

## Why writes need a policy at all Keeping a cache and its backing database consistent requires a policy for what happens on both reads and writes, because a cache is fundamentally a second copy of data that can drift from the source of truth. The three classic strategies — **cache-aside**, **write-through**, and **write-behind** — differ mainly in when and how writes touch the cache, and each makes a different trade between write latency, consistency, and durability risk. ## Cache-aside (lazy loading) Cache-aside, also called lazy loading, is the most common pattern in practice and puts the application (not the cache infrastructure) in charge of populating the cache. - **On a read**, the application checks the cache first; on a hit, it returns the cached value directly. - **On a miss**, the application queries the database itself, returns the result to the caller, and — as a separate step — writes that result into the cache so the next read is a hit. - **On a write**, the application writes to the database and then either deletes the corresponding cache entry (invalidate) or updates it directly; deleting is generally preferred because it avoids a subtle race where a slow read that started before the write repopulates the cache with data that's already stale by the time it writes it back. Crucially, the cache is completely passive here: it doesn't know how to load data on its own, and it starts empty for any key until something reads it. Cache-aside's strength is simplicity and resilience: because the database is always the durable source of truth for writes, a cache crash never loses data — it just means more cache misses (and therefore more database load) until the cache warms back up. Its weakness is a staleness window: between the database write and the cache-delete (or between an in-flight stale read repopulating the cache), readers can briefly see old data, and under high write concurrency this window can widen. ## Write-through Write-through makes the cache an active participant in every write: the application (or a caching layer that wraps the database) writes to the cache and the database together as part of a single logical write operation, and the write is only considered complete once both succeed. This guarantees the cache is never behind a committed write — any subsequent read is guaranteed fresh, because the cache and database are updated atomically from the caller's perspective. The cost is **write latency**: every write now pays for two synchronous operations (cache write plus database write) instead of one, and if the two can't be made truly atomic, there's a narrow window where one succeeds and the other fails, requiring compensating logic. Write-through also caches everything that's written, even data that's rarely or never subsequently read, which can waste cache memory on cold data — a mismatch it shares with any policy that writes to cache eagerly rather than lazily on first read. ## Write-behind (write-back) Write-behind (also called write-back) also writes to the cache first, but instead of synchronously propagating to the database, it acknowledges the write to the caller immediately and flushes to the database asynchronously later — often batching multiple writes to the same key into a single database write, or coalescing many writes over a short window to reduce database load dramatically. This gives the lowest possible write latency from the caller's perspective and the highest write throughput, since the database is shielded from the full write rate and can be updated in efficient batches. The trade-off is a **durability and consistency risk**: there's a window during which the authoritative copy of the data lives only in the cache and not yet in the database. If the cache node crashes, loses power, or is evicted before the flush completes, those writes are permanently lost unless the cache itself is made durable (e.g., persisted to disk, replicated). It also means any process reading directly from the database — bypassing the cache — can see stale or missing data during that window, so write-behind is only safe when all reads are guaranteed to go through the same cache. ## Choosing between them Choosing between them is a direct trade of write latency and cache-infrastructure complexity against consistency and durability guarantees. - **Cache-aside** is the default for most web applications and read-heavy workloads (e.g., a `Redis` cache in front of a `Postgres` database for a typical CRUD API) precisely because it's simple, database-is-truth, and cache failure is a performance problem rather than a data-loss problem. - **Write-through** suits systems that need read-after-write consistency guarantees and can tolerate the extra write latency — for example, a session store where a user's next request must always see their just-written session state. - **Write-behind** suits extremely write-heavy systems where database write capacity is the bottleneck and some risk of losing the most recent few writes on a crash is acceptable — for example, batching high-frequency metrics or activity-log writes, or systems like CPU/disk caches at the hardware level, which is where the write-back terminology originates.