Skip to content
Back to System DesignAll lessons

System Design

Caching Strategies (Write-Through vs Write-Back)

O(1) time per cache read or write in both strategies. Write-through pays one extra O(1) database write on every single write. Write-back puts off that cost. It flushes many writes to the database in one batch, later. That's faster now, but anything still 'dirty' is lost if the cache disappears before the flush.

The idea, in plain English

Imagine you keep a small notebook on your desk — a fast 'cache' — instead of always walking to the filing cabinet in the basement, the slower real database. Write-through means this: every time you jot something in the notebook, you also walk down and update the filing cabinet right away. It's slower per write, but the two always agree. Write-back (also called write-behind) means this: you jot it in the notebook and keep working. The filing cabinet gets updated later, in a batch. Writes feel instant. But if your notebook page got lost before that trip to the basement, that update is gone.

How it works

  1. 1Keep two stores: a fast cache and a slower real database.
  2. 2Write-through: on every write, update the cache and the database right away, before telling the caller 'done.' Reads always match between the two.
  3. 3Write-back: on every write, update only the cache, and mark that entry 'dirty' — changed but not yet saved. A later step, called a 'flush,' copies all dirty entries into the database and clears the dirty marks.
  4. 4Reads always check the cache first. If the data isn't there, fall back to the database.

When you'd use it

Use this once your app is popular enough that hitting the real database on every write slows everything down. Write-through is worth the extra cost when you can never afford to lose a write — like a bank balance. Write-back is worth the risk when writes happen often, and a short window of possible data loss is acceptable in exchange for speed — like counting 'likes' on a post. That data loss could happen if the server crashes before flushing.

Common beginner mistakes

  • Picking write-back for data you can never afford to lose — like 'has this user paid?' — without realizing that a crash before the flush means that write never reaches the real database.
  • Forgetting to check the cache on reads, and going straight to the database anyway. That throws away the entire speed benefit of having a cache.

Try it — edit and run

Click the code to edit · press ⌘/Ctrl+↵ to run

Editable code. Tab and Shift+Tab indent. Press Escape, then Tab, to move focus out of the editor.

Expected output — hit Run to try it
-- Write-through: cache and database updated together --
cache: user:1=Alice, user:2=Bob
database: user:1=Alice, user:2=Bob
-- Write-back: cache updated now, database updated later --
cache: user:1=Alicia, user:2=Bob, user:3=Carol
database (not flushed yet): user:1=Alice, user:2=Bob
Flushed keys: user:1, user:3
database (after flush): user:1=Alicia, user:2=Bob, user:3=Carol

Not sure this is the right topic? See the learning paths → or where this leads →