Cache Write Strategieslesson 5 of 5 · 3 min read

Picking a Combination

Not rivals, columns in a spreadsheet

These strategies are not rivals. They are answers for different columns of the same spreadsheet.

Avoid the mistake interviewers watch for, which is picking one pattern for the whole design. Real systems mix them per data type, because the questions that select a pattern are properties of the data rather than of the system.

Ask three questions of each thing you cache. How soon after a write is it read back? Seconds puts you in write-through territory, and hours or never points at write-around.

Ask what losing an acknowledged write costs you. If the answer is money or trust, write-behind is off the table. If it is a slightly wrong counter, write-behind is the cheapest capacity you will ever buy.

Ask what fraction of your writes are ever read again. Below roughly half, writing through the cache is mostly pollution.

One product, three combinations

Run a typical product through those questions. Sessions and cart state get read straight after writing and losing them is annoying but survivable, so write-through with a modest expiry.

Your product catalogue is written rarely by merchants and read constantly, so write-around with delete-on-write and cache-aside reads.

Your view counters are written constantly and losing a few is invisible, so write-behind with batched flushes. Three data types, three combinations, one cache cluster.

Give invalidation design time before your cache ships, whichever combination you chose. The old line about it being one of the two hard problems survives because the failure is silent. Nothing crashes, no alert fires, and people just see wrong data and lose a little trust per page.

Decide per data type who deletes or updates the key, what the expiry backstop is, and what the maximum staleness works out to. If you cannot say that window in seconds for a given key, you have not finished designing it.

Worked example

Tom's team is designing checkout for a flash-sale site and does the spreadsheet exercise in one meeting. Cart contents: written and re-read within seconds during the sale rush, so write-through, TTL 30 minutes. Product details: updated a few times a day by merchandising, read 50,000 times a second at peak, so write-around plus a Kafka-driven cache delete on catalog updates, TTL 10 minutes as a backstop. The hype counter showing how many people are viewing an item: write-behind, flushing to Postgres every 5 seconds, and everyone signs off that a crash losing 5 seconds of it costs nothing. Six months later the only cache bug is in the one item that skipped the meeting, a promo banner cached with no TTL that kept advertising a sale for 40 minutes after it ended.

Cache Write Strategies: wrapping up

In the real world

01DynamoDB Accelerator (DAX) implements write-through paired with read-through: a successful write lands in both the table and the cache before the SDK call returns.
02Facebook's memcache architecture is write-around in spirit: writes go to MySQL, an invalidation pipeline (mcsqueal) tails the commit log and deletes affected cache keys across clusters.
03CPU caches and operating system page caches use write-back with dirty pages flushed later, which is why an unclean shutdown can lose recently written file data unless fsync forced it out.
04Redis is commonly deployed as a write-behind buffer for counters and metrics, with workers draining aggregated increments into a relational store on an interval.
05Stripe and other payment companies keep money writes strictly in transactional databases and use caches only on read paths, a deliberate refusal of write-behind where loss is unacceptable.

Questions people ask

Is write-behind ever safe for important data?

Only if you add durability the cache itself does not provide, like writing to a replicated log such as Kafka before acknowledging, at which point you have rebuilt a different architecture. As a plain cache pattern, write-behind trades a window of data loss for speed, so reserve it for data where losing a few seconds of writes costs effectively nothing.

Why not just use write-through everywhere and stop worrying about staleness?

Two costs. Every write pays a second round trip, which matters on hot write paths, and every written key consumes cache memory whether or not anyone reads it, which evicts genuinely hot data on write-heavy workloads. Write-through is the right tool for read-after-write data, and wasteful for data written often and read rarely.

What does cache invalidation actually mean in this context?

Removing or expiring a cached entry because the underlying data changed, so readers stop seeing the old value. The main mechanisms are TTL expiry, explicit deletes triggered by writes, and versioned keys that make old entries unreachable. Most production setups layer at least two of these, using explicit deletes for freshness with a TTL as the safety net.

Quick review

Write-Through:: write to cache AND DB synchronously. Strong consistency. Higher write latency (waits for both)
Write-Behind (Write-Back):: write to cache only; async flush to DB later. Low write latency; data loss risk on crash
Write-Around:: write directly to DB, skip cache. Cache populated only on next read. Good for write-once data (logs)
Popular combo:: Write-Around + Cache-Aside. Avoids polluting cache with rarely-re-read data
Cache invalidation strategies:: TTL (time-based expiry), event-driven invalidation (on DB write), cache-busting (version in key); Cache invalidation is one of the two hard problems in CS. Design your invalidation strategy before your caching strategy

the trade-off

Write-Behind: data loss if cache crashes before flushing. Write-Through: slower writes (both cache + DB must ack).

in the room

Write-Through for strong consistency. Write-Behind for write-heavy with tolerable data loss. Write-Around for write-once.

the short version

Read and write strategies are chosen per data type, not once per system.