Cache-Aside vs Write-Through

Cache-aside vs write-through: who updates the copy, and when

4 min read

Cache-aside fills the cache lazily, on a read miss, and invalidates it on a write, so between that write and the next read the cache can still hand back the old value; write-through writes the cache and the database as a single operation and returns only after both succeed, so a read taken right after a write always sees the new value. That is the difference between cache-aside and write-through: not raw speed, but the moment the copy and the original stop disagreeing.

The two are only fairly compared at one frame — a write, and the read that immediately follows it. Cache-aside is really a read strategy with an invalidation rule; write-through is a write strategy. Line them up at that shared moment and the contrast is exact: one refills the copy after the fact, the other never lets it fall behind.

Cache-aside: the application owns the detour

In cache-aside the cache is passive. On a read the application asks the cache for a key; on a miss the cache does not go and fetch anything, so the application reads the database itself, writes the row back into the cache, and returns it. The next read for that key is a hit and skips the database entirely. On a write the application updates the database and invalidates the cached entry; the entry is repopulated on the next read, not on the write.

That invalidation is the whole story. Between the write and the next read there is a window: a reader either takes a miss, or — if the invalidation races the write — briefly sees the old value. Azure's guidance documents this directly, and it is the pattern working as designed, not a bug in your code. The upside is real: the cache only ever holds keys someone actually read, and if the cache goes down the application still reaches the database on its own.

Write-through: both copies settle in one operation

Write-through moves the work to write time. The application — or the cache library, in the packaged version — writes the cache and then writes through to the database as part of the same operation, and the call returns only after both succeed. A read that follows immediately sees the new value, because there is no moment when only one copy has been updated. The staleness window is closed by construction.

That freshness is not free, and a page that sells it as a free win is lying by omission. Every write now pays two hops before the caller is released, plus the coordination logic to stay consistent when the second write fails. You also cache keys that get written but may never be read. Write-through buys read-after-write correctness with write latency.

When to use cache-aside

The short version of when to use cache-aside: reach for it when the workload is read-heavy and short-lived staleness is tolerable — a product listing, a profile, a feed. You get a cache that fills only with what is actually read and keeps serving from the database if the cache dies. Choose write-through instead when a read right after a write must be correct — an account balance the user just changed, a setting they expect reflected instantly — and the extra write latency is a price you can pay. Neither is the wrong answer; they encode different tolerances for a stale read.

Cache invalidation strategies

Cache-aside is itself one of the two common cache invalidation strategies: delete the entry on write and let the next read refill it. The other is a TTL — give every entry a time-to-live and let it expire on its own. Explicit invalidation is precise but easy to forget on some write path; a TTL is a blunt staleness budget that needs no write-side code but serves stale data until it lapses. Most systems run both: invalidate on the writes you control, and set a TTL as the backstop for the ones you miss.

Write-through vs write-behind

The synchronous cost of write-through is exactly what write-behind tries to dodge, so write-through vs write-behind is the follow-on decision. Write-behind (write-back) acknowledges the write as soon as the cache is updated and flushes to the database asynchronously. Writes get faster and the two copies still converge — but it is the one strategy of the three that can lose data, because if the cache dies before the flush the acknowledged write is gone. Write-through trades latency for durability; write-behind trades durability for latency.

Cache-Aside vs Write-Through in a system design interview

An interviewer is rarely asking which is faster. They are checking whether you know you have picked a consistency policy, not just a speed optimisation. The crisp answer: cache-aside populates on a read miss and invalidates on write, so it carries a staleness window and tolerates a dead cache; write-through updates both in one operation and returns only after both succeed, so it gives read-after-write freshness at the cost of write latency. Say which you would use and why, name the staleness window explicitly, and mention write-behind as the asynchronous variant that trades durability for speed. That is the answer that shows you understand the axis, not just the labels.

Sources

• Azure Architecture — Cache-Aside pattern
• Azure Architecture — Write-Through caching
• Azure Architecture — Caching guidance