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.

Practice

1. What is the main advantage of using the write-behind pattern in Redis?

easy

A. It deletes data from Redis immediately after writing to the main database.

B. It requires no background process to sync data.

C. It speeds up data writes by saving to Redis first, then updating the main database later.

D. It stores data only in the main database without caching.

Solution

1. Step 1: Understand write-behind pattern basics

   The write-behind pattern saves data quickly in Redis first, avoiding slow direct writes to the main database.

2. Step 2: Identify the benefit

   This approach improves application speed by deferring the main database update to a later time via a background process.

3. Final Answer:

   It speeds up data writes by saving to Redis first, then updating the main database later. -> Option C

4. Quick Check:

   Write-behind pattern = Fast Redis write + delayed DB update [OK]

Hint: Remember: write-behind means write fast in Redis, sync later [OK]

Common Mistakes:

• Thinking data is deleted immediately from Redis
• Assuming no background sync is needed
• Confusing write-behind with write-through pattern

2. Which Redis command is typically used to save data immediately in a write-behind pattern?

easy

A. SET

B. DEL

C. GET

D. EXPIRE

Solution

1. Step 1: Identify command to save data in Redis

   The SET command stores a key-value pair in Redis immediately.

2. Step 2: Confirm other commands' purpose

   GET reads data, DEL deletes keys, and EXPIRE sets expiration time, so they don't save data.

3. Final Answer:

   SET -> Option A

4. Quick Check:

   SET saves data in Redis [OK]

Hint: SET command writes data; GET reads it [OK]

Common Mistakes:

• Choosing GET instead of SET
• Confusing DEL with saving data
• Using EXPIRE to save data

3. Consider this Redis write-behind setup: data is saved with SET user:1 "Alice" and a background process syncs to the main DB every 5 seconds. What happens if the Redis server crashes before sync?

medium

A. Data is safely stored in the main database already.

B. Data is lost because it was only in Redis and not yet synced.

C. Redis automatically syncs data before crashing.

D. Data remains in Redis after restart without loss.

Solution

1. Step 1: Understand write-behind timing

   Data is first saved in Redis, then synced to the main database later by a background process.

2. Step 2: Analyze crash impact before sync

   If Redis crashes before syncing, data only in Redis is lost because it was not yet saved to the main database.

3. Final Answer:

   Data is lost because it was only in Redis and not yet synced. -> Option B

4. Quick Check:

   Unsynced Redis data lost on crash [OK]

Hint: Unsynced Redis data is volatile; backup often [OK]

Common Mistakes:

• Assuming data auto-syncs before crash
• Thinking Redis data persists after crash
• Believing main DB has data before sync

4. You implemented a write-behind pattern but notice data inconsistencies in the main database. Which fix addresses this issue?

medium

A. Delete data from Redis immediately after writing.

B. Remove Redis and write directly to the main database only.

C. Use Redis GET commands more frequently.

D. Add a reliable background process to sync Redis data to the main database.

Solution

1. Step 1: Identify cause of inconsistencies

   In write-behind, inconsistencies happen if Redis data is not synced properly to the main database.

2. Step 2: Choose the fix

   Adding a reliable background sync process ensures Redis data updates the main database correctly, fixing inconsistencies.

3. Final Answer:

   Add a reliable background process to sync Redis data to the main database. -> Option D

4. Quick Check:

   Reliable sync fixes write-behind inconsistencies [OK]

Hint: Background sync is key to consistency [OK]

Common Mistakes:

• Removing Redis defeats write-behind purpose
• Using GET commands doesn't fix sync issues
• Deleting Redis data too early causes data loss

5. You want to implement a write-behind pattern in Redis for a user profile system. Which approach best ensures data durability and performance?

hard

A. Save user data with SET in Redis, then use a background worker to batch update the main database every minute.

B. Write user data directly to the main database only, skipping Redis.

C. Use Redis GET to read data and update main database synchronously.

D. Delete user data from Redis immediately after saving to main database.

Solution

1. Step 1: Understand write-behind goals

   Write-behind aims to save data fast in Redis and update the main database later to improve performance.

2. Step 2: Evaluate options for durability and speed

   Saving with SET in Redis and batching updates with a background worker balances speed and durability well.

3. Step 3: Reject other options

   Direct writes skip caching, synchronous updates slow performance, and immediate deletes lose Redis benefits.

4. Final Answer:

   Save user data with SET in Redis, then use a background worker to batch update the main database every minute. -> Option A

5. Quick Check:

   Write-behind = fast Redis write + batch DB sync [OK]

Hint: Batch DB updates after fast Redis writes for best results [OK]

Common Mistakes:

• Skipping Redis cache loses speed benefits
• Syncing synchronously slows app
• Deleting Redis data too soon causes data loss