Write-through, write-back, write-around

Cache-aside answers the read side: check the cache, fall back to the database. But data also gets written, and the moment you write, you have two copies to keep in step. There are three classic ways to do it, and they differ in one thing that matters a lot: what you lose if the cache dies at the wrong moment.

The question every write has to answer

When the organiser changes the Gold tier price from ₹2,499 to ₹2,999, the write has to reach the database eventually, because that's the source of truth. The choices are about the cache:

• Does the write go to the cache too, or only to the database?
• Does the user wait for the database, or only for the cache?

Mix those answers and you get three strategies. Their names sound alike, so anchor each to one sentence:

• Write-through: write the cache and the database, then reply.
• Write-back (or write-behind): write the cache, reply, and copy to the database later.
• Write-around: write only the database. The cache picks it up on the next read.

Write-through: always in step

The app writes the new value to the cache and to the database, and replies only when both have it. Reads right after the write hit the cache and see the new price.

• What you get: the cache is never behind the database for data written this way. Nothing is lost if the cache dies, because the database already has every write.
• What you pay: every write waits for both. You also cache every written value, including ones nobody will read soon, which wastes memory.
• The catch: "write both" is two operations, not one. If the database write fails after the cache write succeeded, the cache holds a value that never happened. Write the database first and treat a failed cache write as "delete the key", and you're back to cache-aside with an update instead of a delete.

Good fit: data that is read soon after it's written, like a user's profile after they edit it.

Write-back: fast, with a risk

The app writes only to the cache and replies at once. A background process copies changed values to the database later, every few seconds or when enough changes pile up. Several writes to the same key collapse into one database write.

• What you get: writes as fast as memory, and far fewer database writes. Ten thousand "+1 view" updates to one counter become one UPDATE … SET views = views + 10000.
• What you pay: for a while, the only copy of the latest data is in the cache. If the cache crashes before flushing, those writes are gone, and the user was already told they succeeded.

That makes write-back a poor fit for anything you promised a customer. A booked seat, a payment, a changed price: none of those can live only in RAM. It's a great fit for data where losing a few seconds is acceptable and volume is huge: view counters, "interested" clicks, analytics events, rate-limit counters.

Write-around: skip the cache

The app writes only to the database and deletes (or ignores) the cached copy. The next read misses, loads the new value and caches it.

• What you get: the cache only holds things someone actually read, and the write path is plain database code. This is exactly cache-aside with delete-on-write from lesson 3.3.
• What you pay: the first read after every write is a miss. If data is usually read straight after being written, you're paying for that miss every time.

Good fit: data written often but read rarely, or written once and read later, like a ticket PDF generated at booking and opened on the day of the show.

Try it

Change the price a few times, read it, then crash the cache. Do it once with a flush before the crash, and once without.

Interactive

Three write strategies, side by side

The organiser changes the Gold tier price. Send writes and reads, flush the write-back buffer, then crash the cache and see what each strategy loses.

Change price to ₹2,999 Read price Flush write-back Crash the cache Reset

Write-through

Write the cache and the database together, then reply.

cache

₹2,499

database

₹2,499

last op

–

writes lost

0

Cache and database agree.

Write-back

Write the cache, reply, copy to the database later.

cache

₹2,499

database

₹2,499

last op

–

unflushed

0

writes lost

0

Cache and database agree.

Write-around

Write only the database. The cache fills on the next read.

cache

₹2,499

database

₹2,499

last op

–

writes lost

0

Cache and database agree.

Notice how each column behaves:

• Write-through is the slowest write and loses nothing.
• Write-back is the fastest write. With unflushed writes, a crash sends the database back to an older price, while the organiser's screen said the change was saved.
• Write-around's first read after each write is a miss. After that it's indistinguishable from the others.

Check yourself

Gatepass shows a live 'people interested' counter on each event, bumped thousands of times a second during an announcement. Which strategy suits it?

AWrite-through, so the database is always exactBWrite-back, flushing totals every few secondsCWrite-around, so the cache isn't pollutedDNo cache; write each click straight to the database

Choosing, in practice

Most applications end up mixing them by data type, and that's fine:

Gatepass data	Strategy	Why
Bookings, payments, prices	Write-around (DB, then delete key)	Must never be lost; correctness first
User profile edits	Write-through	Read immediately after, on the next page
View and interest counters	Write-back	Huge volume, losing a few seconds is fine
Ticket PDFs	Write-around	Written once, read days later

Your turn

A teammate proposes write-back for bookings 'so checkout feels instant during the band's sale'. Write the two strongest objections, and suggest what you'd do instead.

01

02

03

Compare with an expertWrite at least 2 first.

Key takeaways

• Write-through writes both before replying: slower writes, nothing lost, cache always current.
• Write-back writes the cache and flushes later: fastest writes and fewer database writes, but a crash loses unflushed data.
• Write-around writes only the database: simple and safe, with a miss on the first read after each write. Paired with cache-aside, it's the default for most data.
• Choose per data type. Anything you promised a customer goes to the database before you reply.