Most system design candidates know what a cache is. Fewer know how data gets into it. Even fewer can explain the consistency implications of each approach.
Here are the three cache write strategies, when each breaks, and how to choose between them in an interview.
Write-through
When a write happens: update the cache and the database simultaneously. Both are updated before the write is acknowledged to the caller.
Consistency model: strong. Any subsequent read from the cache will see the latest write. The cache is always in sync with the database.
The cost: every write takes longer. The caller waits for both the cache and the database to confirm. For read-heavy systems where cache consistency is critical and writes are infrequent, this is the right trade-off.
Where it breaks: under heavy write load. If you’re processing 50,000 writes per second, waiting for both cache and database on every write doubles your write latency. You also write to the cache even for data that will never be read — if you write a user’s address and nobody reads that user’s profile for a month, the cache entry was wasted.
Use write-through when: the data is read frequently after each write, and consistency between cache and database is required at all times. User profile reads immediately after an update. Configuration changes that must be reflected immediately.
Write-back (write-behind)
When a write happens: update the cache immediately and acknowledge to the caller. Write to the database asynchronously in the background.
Consistency model: eventual between cache and database. The cache has the latest data. The database lags by whatever the flush interval is.
The benefit: write latency is extremely low — the caller doesn’t wait for the database.
Where it breaks: if the cache node fails before the flush, the writes are lost. This is a real data loss scenario. Write-back is not appropriate for financial data, user records, or anything where losing a write is unacceptable.
Use write-back when: write latency is critical and some data loss under failure is acceptable. Analytics counters. Non-critical telemetry. Systems where re-deriving the data from another source is possible.
Write-around
When a write happens: write directly to the database, bypassing the cache entirely. The cache is only populated on read (when a cache miss occurs and the data is fetched from the database).
Consistency model: strong. The database is always the source of truth. The cache holds whatever was last read.
Where it breaks: high cache miss rate for new or recently-written data. If you write data and immediately read it, the first read is always a cache miss. Under write-heavy workloads where most new data is read immediately, write-around causes a flood of cache misses.
Use write-around when: data is written once and rarely read, or the write pattern and read pattern are decoupled. Large file writes (S3 is the database, CDN is the cache — write to S3, CDN populates on first request). Logging. Batch import jobs where the imported data isn’t immediately queried.
How to choose in an interview
The decision follows from two questions:
First: how often is data read immediately after it’s written? If frequently → write-through or write-back (cache gets populated on write). If rarely → write-around (avoid polluting cache with data nobody reads).
Second: can you tolerate data loss on cache failure? If no → write-through (database always has the data). If yes → write-back (lowest write latency).
The standard production pattern for a read-heavy web application: write-through for user data and configuration, write-around for analytics and logging, write-back only for session counters and similar low-stakes high-frequency writes.
Naming the strategy is the L4 answer. Naming the strategy plus the failure mode plus the condition under which you’d switch is the L5 answer. Adding the monitoring signal that tells you the strategy is no longer appropriate (cache hit rate dropping, write latency spiking) is the L6 answer.
CTA: The cohort curriculum cuts through high-level cache definitions — teaching you how to rigorously evaluate write-through, write-back, and write-around strategies against latency, consistency, and failure modes, and how to scale your architectural reasoning from L4 implementation choices to L6 operational monitoring signals.
Subscription link
https://systemdr.systemdrd.com/subscribe
Want the full picture?
The premium lessons include advanced insights, practical exercises, and comprehensive walkthroughs.