Write-Through vs Write-Back
Reads are easy. Writes are where caching patterns split apart.
A quick recap of cache-aside
The most common pattern is cache-aside. It is sometimes called "look-aside."
On a read, you check the cache first. A hit returns instantly. A miss falls through to the database. Then you store the answer in the cache so the next read is a hit.
On a write, you update the database. Then you delete the matching cache entry so the next read fetches fresh data.
It is simple. The app manages the cache. The cache does not even need to know the database exists. Most apps use this. But it has a small gap. Between updating the database and clearing the cache, some readers can still see old data. The other strategies fix this gap in different ways.
Write-through. Update both at the same time
In write-through, every write goes to the cache AND the database. Both happen as part of the same operation. The write does not return success until both stores are updated.
The cache is always in sync with the database. There is no stale data. No invalidation step. Reads always hit the cache and always see fresh values.
The cost is speed. Writes are slower because you wait for two stores instead of one. If the database is slow, the user feels it. If the cache is down, the write fails.
You see this in write-heavy systems that need strong consistency. Banking apps are a good example. Some database engines use write-through inside themselves, where the disk is the "database" and RAM is the "cache."
Write-back. Write fast now, save later
In write-back (also called "write-behind"), the write only goes to the cache. The cache says "got it" right away. A background job pushes the data to the database later.
The good part is speed. Writes happen at RAM speed, not disk speed. Throughput is very high. If the same key is written 100 times before the next flush, only the final value goes to disk.
The bad part is risk. If the cache server crashes before it flushes, those writes are gone. You traded safety for speed. Recovery is complex.
You see this in high-frequency analytics, IoT metrics, and anything where losing the last few seconds of data is fine. You do NOT use this for orders or payments.
Which one should you pick
Cache-aside is the safe default. Most apps use it. It is easy to reason about. It survives cache failures. Things just get slower if the cache is down.
Write-through is for when consistency matters and your write rate is not the bottleneck. It is often paired with "read-through," where the cache fetches from the database on a miss instead of the app doing it.
Write-back is only for when speed beats safety. It is rare. It comes with extra operational pain.
Most apps use cache-aside on the outside and write-through inside the database engine. Write-back is the exception, not the rule.
There is no "best" pattern. There is only the right pattern for your workload.