Write-Behind Cache

When building highly interactive applications, read speeds are only half the battle. What happens when your application is incredibly write-heavy?

Imagine a system that tracks the number of likes on a viral TikTok video. During peak virality, that video might receive 10,000 likes per second. If your application tries to execute an UPDATE videos SET likes = likes + 1 SQL query on your primary database 10,000 times a second, the database will quickly lock up, max out its disk I/O, and crash.

Databases are safe, but writing to disk is slow. To solve this, we use a pattern called Write-Behind (also known as Write-Back) caching.

What is a Write-Behind Cache?

In a Write-Behind pattern, the application treats the Cache as the primary write target. When the application needs to save data, it writes it only to the cache, and immediately returns a success response to the user.

Later, asynchronously in the background, a worker process reads the updated data from the cache and flushes it to the slower, persistent database.

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

Write path: the app writes only to Redis and returns immediately. The database is not touched, giving sub-millisecond write latency even at 10,000 writes per second.

1 / 10.5×1×2×3×Playground

Write path: the app writes only to Redis and returns immediately. The database is not touched, giving sub-millisecond write latency.

The Analogy: The Restaurant Tab

Imagine you're at a crowded bar. Every time you order a $5 beer, the bartender doesn't run to the back office, log into the bank, and run your credit card right then and there. It would take too long, and a line would form out the door.

Instead, the bartender keeps a running tab on a notepad (the Cache). "One beer for Alice." -> Alice's tab is now $5. "Another beer for Alice." -> Alice's tab is now $10.

Alice gets her beers instantly (fast write performance). At the end of the night, when things are quiet, the bartender takes the notepad and finally charges Alice's credit card for the total $10 (the asynchronous database write).

How it works step-by-step

Let's look at the viral video "Likes" scenario:

1. The Write: A user clicks "Like". The application connects to Redis and increments a counter: INCR video:123:likes.
2. Instant Response: Redis confirms the write in a fraction of a millisecond. The user's UI instantly updates.
3. Batching: Over the next 5 seconds, 50,000 other people click "Like". Redis rapidly increments the counter in memory.
4. The Flush (Behind the scenes): A background cron job or worker runs every 10 seconds. It checks Redis, sees that video:123:likes is now at 50,000. It connects to the Postgres database and runs a single query: UPDATE videos SET likes = 50000 WHERE id = 123.

We just collapsed 50,000 expensive database operations into a single query.

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

Flush phase: a background worker reads all dirty keys from Redis every 10 seconds and collapses them into a single database query. 50,000 writes become one UPDATE.

1 / 10.5×1×2×3×Playground

Flush phase: a background worker reads dirty keys from Redis and collapses them into a single database query every 10 seconds.

Real-World Examples

• YouTube/TikTok View Counters: View counts are famously eventually consistent. They are aggregated in fast memory stores (like Redis) and flushed to the primary database in batches periodically.
• Gaming Leaderboards: In intense multiplayer games, player scores change multiple times a second. Constantly writing this to a relational database would lag the game. The score is updated in memory and flushed to the database every few minutes.
• Analytics/Telemetry: If you are tracking every mouse click a user makes on your website, you write those events to a high-speed memory buffer or queue, and later batch-insert them into a data warehouse.

Pros of Write-Behind

1. Extreme Write Performance: Because the application only waits for RAM (the cache) to confirm the write, write latency is virtually zero. You can handle massive spikes in write traffic.
2. Database Protection: It shields the database from being overwhelmed. By batching updates (e.g., saving the final state of a counter rather than every incremental step), you drastically reduce database load.

Cons and Trade-offs

The Write-Behind pattern comes with a serious risk: Data Loss.

Because you are telling the user "Success! Your data is saved!" when the data is actually only sitting in volatile RAM, what happens if the cache server's power cord gets unplugged?

If the Redis server crashes before the background worker flushes the data to the database, that data is permanently lost. Alice gets 10 beers, but the bartender's notepad burns in a fire before he charges her card. The bar loses the money.

For this reason, Write-Behind is strictly used for data where some level of loss is acceptable. It's fine if a video loses 5 seconds worth of "Likes" during a crash. It is absolutely unacceptable to use Write-Behind for financial transactions or healthcare records.

Summary

The Write-Behind pattern flips traditional caching on its head by writing data directly to the cache and asynchronously syncing it to the database later. It provides very fast write speeds and protects databases from traffic spikes by batching updates. However, because data lives temporarily only in volatile memory, it introduces a real risk of data loss if the cache fails before the sync occurs. Use it for high-volume metrics, but never for critical transactional data.