Writing Policies

In one line: the write policy decides whether your cache can lose acknowledged data, and whether a write costs one round trip or two. It is the first real trade-off in the design.

The three policies

Policy	What happens	Gains	Costs
Write-through	Data written to cache and database in the same operation	Strong consistency between cache and database	Increased write latency — complete only after both writes succeed
Write-back	Written to cache first, then to storage asynchronously	Low write latency	Risk of data loss if the cache fails before persisting; temporary inconsistency
Write-around	Written directly to the database, bypassing the cache; loaded on a subsequent read miss	Avoids filling the cache with potentially unused items	First read after a write is always a miss

Choosing one

Situation	Policy	Why
Write, then read back promptly, with consistency required	Write-through	The data is in the cache the moment the write completes, and cache and database agree
Write-heavy workload where latency dominates	Write-back	The database write is off the critical path
Data written but rarely re-read soon after	Write-around	Avoids polluting the cache with entries nobody will request

The first row is the classic interview question

"A system wants to write data and promptly read it back, while keeping cache and database consistent. Which policy?"

Write-through. Write-back leaves a window where the database is behind — and worse, the data could be lost entirely if the cache dies before flushing. Write-around guarantees the immediate read-back is a miss, which is exactly the opposite of what was asked.

Write-through is the only one that satisfies both halves of the requirement, and you pay for it in write latency.

Write-back can lose acknowledged writes

This is the same durability problem as asynchronous replication from the databases material, in a sharper form. The client is told the write succeeded once it is in the cache — which is volatile RAM. If the cache node dies before the asynchronous flush, that write is gone with no record it ever existed.

For a view counter or a session timestamp that may be fine. For anything the business would miss, write-back means accepting data loss as a design position, not an accident. State it as a choice.

The read pattern has a name too

Write policies get all the attention; the read side has its own pattern and it is worth naming because interviewers use the term.

Cache-aside — also called look-aside or lazy loading — puts the application in charge: it checks the cache, falls back to the store on a miss, and populates the cache itself. The cache never talks to the database.

Two properties follow, and both are why it dominates in practice.

Only requested data is ever cached, so the cache fills with what is actually read rather than with everything written. For a store where most rows are never read, that difference is enormous.

A cache failure is survivable. Every read has a defined path to the database already, so losing the cache degrades latency rather than availability. Contrast a read-through cache, where the application only knows how to talk to the cache and an outage there is an outage everywhere.

The cost is that the first read of anything is always a miss, and that the application carries the population logic in every call site — which is what makes a consistent client library worth having.

The general shape

Write-through  ->  consistency, at the cost of latency
Write-back     ->  latency, at the cost of durability
Write-around   ->  cache purity, at the cost of first-read misses

There is no single optimal choice — the policy depends on application requirements, and a system with several data types reasonably uses different policies for each.

Key takeaway

Write-through when correctness matters and you can afford the latency. Write-back when latency matters and you can afford to lose recent writes. Write-around when the data will not be read back soon.

Interview signal by level

Level	What a strong answer sounds like
L4	"We write to the cache and the database."
L5	Names the policies: "write-through for consistency, write-back if we need low write latency, write-around for data we won't re-read."
Staff+	Prices the durability: "write-back acknowledges from volatile RAM, so a node dying before the flush loses an acked write — that's a deliberate position, not a detail. I'd use write-through for anything user-visible and write-back only where losing recent data is genuinely acceptable."

Next: making room when the cache fills.