Write-behind pattern in Redis - Step-by-Step Execution

Concept Flow - Write-behind pattern

Client writes data to cache

↓

Cache stores data immediately

↓

Write operation queued

↓

Background process writes data to DB

↓

DB updated asynchronously

↓

Client reads get latest from cache

Client writes data to cache first; cache stores it and queues write to database. Background process updates DB later, so writes are asynchronous.

Execution Sample

Redis

SET user:1:name "Alice"
# Cache stores immediately
# Write queued
# Background writes to DB
GET user:1:name

Client sets a value in Redis cache; cache stores it immediately and queues DB write; client reads from cache.

Execution Table

Step	Action	Cache State	Write Queue	DB State	Output
1	Client issues SET user:1:name "Alice"	{"user:1:name": "Alice"}	[('user:1:name', 'Alice')]	{"user:1:name": null}	OK
2	Write operation queued for DB	{"user:1:name": "Alice"}	[('user:1:name', 'Alice')]	{"user:1:name": null}	—
3	Background process writes to DB	{"user:1:name": "Alice"}	[]	{"user:1:name": "Alice"}	—
4	Client issues GET user:1:name	{"user:1:name": "Alice"}	[]	{"user:1:name": "Alice"}	"Alice"
5	No more writes queued, process idle	{"user:1:name": "Alice"}	[]	{"user:1:name": "Alice"}	—

💡 Write queue empty, DB updated, client reads latest from cache

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
Cache	{}	{"user:1:name": "Alice"}	{"user:1:name": "Alice"}	{"user:1:name": "Alice"}	{"user:1:name": "Alice"}	{"user:1:name": "Alice"}
Write Queue	[]	[('user:1:name', 'Alice')]	[('user:1:name', 'Alice')]	[]	[]	[]
DB	{}	{}	{}	{"user:1:name": "Alice"}	{"user:1:name": "Alice"}	{"user:1:name": "Alice"}
Output	—	OK	—	—	"Alice"	—

Key Moments - 3 Insights

Why does the client get the data immediately after SET even though the DB is not updated yet?

Because the cache stores the data immediately (see Step 1 in execution_table), so GET reads from cache, not DB.

What happens if the background process fails to write to the DB?

The write queue will keep the operation until successful, preventing data loss (Step 2 and 3 show the queue and write).

Why is the write to DB asynchronous and not immediate?

To improve performance and reduce client wait time, writes are queued and done in background (Step 2 and 3).

Visual Quiz - 3 Questions

Look at the execution_table, what is the state of the write queue after Step 3?

A Contains multiple write operations

B Contains one write operation

C Empty list []

D Unknown

💡 Hint

Check the 'Write Queue' column at Step 3 in execution_table

At which step does the DB get updated with the new data?

A Step 1

B Step 3

C Step 2

D Step 4

💡 Hint

Look at the 'DB State' column in execution_table to see when data changes from null to 'Alice'

If the client reads data immediately after Step 1, what value will it get?

A "Alice"

B null

C Error

D Old DB value

💡 Hint

Check the 'Cache State' and 'Output' columns at Step 1 and Step 4

Concept Snapshot

Write-behind pattern:
- Client writes to cache immediately
- Write operation queued for DB asynchronously
- Background process updates DB later
- Reads get latest from cache
- Improves write performance by decoupling DB writes

Full Transcript

The write-behind pattern means when a client writes data, it first goes to the cache. The cache stores it right away and queues the write to the database. A background process then writes the data to the database asynchronously. This way, the client gets fast responses from the cache, and the database is updated later without blocking the client. The execution table shows the cache state, write queue, and database state step-by-step. The client reads the latest data from the cache even before the database is updated. This pattern improves performance by separating cache writes from slower database writes.