Cache stampede prevention in Redis - Step-by-Step Execution

Concept Flow - Cache stampede prevention

Client requests data

↓

Check cache for data

↓

Return cached

↓

Lock acquired?

↓

Fetch from DB

↓

Update cache

↓

Return data to client

When a client requests data, the system checks the cache. If missing, it tries to acquire a lock to fetch from the database and update the cache. Others wait for the cache to be updated to prevent many DB hits.

Execution Sample

Redis

if cache.exists(key):
    return cache.get(key)
if cache.setnx(lock_key, 1):
    data = db.query()
    cache.set(key, data)
    cache.delete(lock_key)
else:
    wait_for_cache_update()
    return cache.get(key)

This code checks cache, acquires a lock to fetch DB data if missing, updates cache, and others wait to avoid multiple DB hits.

Execution Table

Step	Action	Cache State	Lock State	DB Query	Returned Data
1	Client requests data	empty	no lock	no query	none
2	Check cache for key	empty	no lock	no query	none
3	Cache miss, try to set lock	empty	lock set	no query	none
4	Lock acquired, query DB	empty	lock set	query executed	none
5	Update cache with data	data cached	lock set	query done	none
6	Delete lock	data cached	no lock	query done	none
7	Return cached data	data cached	no lock	query done	data returned
8	Another client requests data	data cached	no lock	no query	data returned
9	Check cache for key	data cached	no lock	no query	data returned
10	Cache hit, return data	data cached	no lock	no query	data returned
11	Client requests data, cache empty	empty	lock set by another	no query	none
12	Lock not acquired, wait	empty	lock set	no query	none
13	Cache updated by lock owner	data cached	no lock	query done	none
14	Return cached data after wait	data cached	no lock	query done	data returned

💡 Execution stops after data is returned from cache or DB and lock is released.

Variable Tracker

Variable	Start	After Step 3	After Step 5	After Step 6	After Step 10	After Step 14
cache	empty	empty	data cached	data cached	data cached	data cached
lock	no lock	lock set	lock set	no lock	no lock	no lock
db_query	no query	no query	query executed	query done	no query	query done
returned_data	none	none	none	none	data returned	data returned

Key Moments - 3 Insights

Why do we use a lock before querying the database?

The lock prevents multiple clients from querying the database simultaneously when the cache is empty, as shown in steps 3-6 in the execution_table.

What happens if a client cannot acquire the lock?

The client waits for the cache to be updated by the lock owner, then reads from the cache, as shown in steps 11-14.

Why do we delete the lock after updating the cache?

Deleting the lock signals other clients that the cache is ready to be read, preventing deadlocks and allowing them to get data from cache (step 6).

Visual Quiz - 3 Questions

Look at the execution_table at step 4. What is happening?

A Cache is being updated with data

B Client returns cached data

C Database query is executed after lock acquired

D Lock is deleted

💡 Hint

Check the 'DB Query' and 'Lock State' columns at step 4 in execution_table.

At which step does the lock get released?

A Step 3

B Step 6

C Step 5

D Step 10

💡 Hint

Look at the 'Lock State' column in execution_table to find when it changes from 'lock set' to 'no lock'.

If the cache is already filled, what happens when a client requests data?

A Client returns cached data immediately

B Client queries the database

C Client waits for lock to be released

D Client sets a new lock

💡 Hint

Refer to steps 8-10 in execution_table where cache is 'data cached'.

Concept Snapshot

Cache Stampede Prevention:
- Check cache first for data.
- If missing, try to set a lock (setnx).
- Lock owner queries DB and updates cache.
- Others wait for cache update to avoid multiple DB hits.
- Delete lock after cache update to release waiting clients.

Full Transcript

Cache stampede prevention is a technique to avoid many clients querying the database at once when cache data is missing. The process starts when a client requests data and checks the cache. If the data is not found, the client tries to acquire a lock. If successful, it queries the database, updates the cache, and releases the lock. Other clients that fail to get the lock wait until the cache is updated and then read from the cache. This prevents multiple expensive database queries and reduces load. The execution table shows each step, including cache state, lock state, database queries, and returned data. Key moments include why the lock is used, what happens when the lock is not acquired, and why the lock is deleted after updating the cache. The visual quiz tests understanding of these steps. The snapshot summarizes the main points for quick reference.

Practice

1. What is the main goal of cache stampede prevention in Redis?

easy

A. To allow multiple processes to update cache simultaneously

B. To increase the size of the cache automatically

C. To delete all cache entries periodically

D. To stop many requests from hitting the database at the same time

Solution

1. Step 1: Understand cache stampede problem

   Cache stampede happens when many requests try to refresh expired cache simultaneously, causing database overload.

2. Step 2: Identify the goal of prevention

   Prevention aims to allow only one process to refresh cache, reducing database hits.

3. Final Answer:

   To stop many requests from hitting the database at the same time -> Option D

4. Quick Check:

   Cache stampede prevention = stop many DB hits [OK]

Hint: Cache stampede means many requests hit DB; prevention stops this [OK]

Common Mistakes:

• Thinking cache stampede increases cache size
• Believing cache stampede deletes cache entries
• Assuming multiple processes update cache simultaneously

2. Which Redis command syntax correctly sets a lock with expiration to prevent cache stampede?

easy

A. SET key value NX PX 3000

B. SET key value XX EX 3000

C. GET key NX PX 3000

D. DEL key NX PX 3000

Solution

1. Step 1: Recall Redis SET options for locking

   SET with NX sets key only if it does not exist; PX sets expiration in milliseconds.

2. Step 2: Identify correct syntax

   SET key value NX PX 3000 uses SET with NX and PX correctly to create a lock with 3000ms expiry.

3. Final Answer:

   SET key value NX PX 3000 -> Option A

4. Quick Check:

   SET with NX and PX = lock with expiry [OK]

Hint: Use SET with NX and PX for lock with expiry [OK]

Common Mistakes:

• Using GET instead of SET for locking
• Using XX instead of NX option
• Using DEL command for locking

3. Given this Redis Lua script snippet for cache stampede prevention:

local lock = redis.call('SET', KEYS[1], '1', 'NX', 'PX', 5000)
if not lock then
  return redis.error_reply('Lock not acquired')
end
-- refresh cache here
redis.call('DEL', KEYS[1])
return 'Cache refreshed'

What will be the output if the lock key already exists?

medium

A. Lock not acquired

B. nil

C. Syntax error

D. 'Cache refreshed'

Solution

1. Step 1: Understand SET with NX behavior

   SET with NX returns OK if key set, nil if key exists already.

2. Step 2: Check script logic when lock not acquired

   If lock is nil (not acquired), script returns redis.error_reply('Lock not acquired').

3. Final Answer:

   Lock not acquired -> Option A

4. Quick Check:

   Lock exists -> error reply 'Lock not acquired' [OK]

Hint: If SET NX fails, script returns 'Lock not acquired' error [OK]

Common Mistakes:

• Assuming script returns 'Cache refreshed' always
• Expecting nil instead of error reply
• Thinking script has syntax error

4. You wrote this Redis command to prevent cache stampede:

SET lock_key 1 PX NX 5000

But it does not work as expected. What is the problem?

medium

A. The value '1' is invalid for locking

B. The order of PX and NX options is incorrect

C. SET command does not support NX option

D. PX option requires seconds, not milliseconds

Solution

1. Step 1: Check Redis SET command option order

   Redis requires SET options in order: NX before PX or PX before NX is accepted, but best practice is NX PX.

2. Step 2: Identify issue with given command

   Given command uses PX before NX, which Redis does not accept; correct order is NX PX.

3. Final Answer:

   The order of PX and NX options is incorrect -> Option B

4. Quick Check:

   Correct option order is NX PX [OK]

Hint: Use NX before PX in SET command options [OK]

Common Mistakes:

• Thinking value '1' is invalid
• Believing SET does not support NX
• Confusing PX milliseconds with seconds

5. You want to prevent cache stampede using Redis locks. Which approach correctly handles the scenario where the cache refresh takes longer than the lock expiration time?

hard

A. Do not use PX expiration and rely on manual DEL of lock key only

B. Set a very short PX expiration to release lock quickly and retry immediately

C. Set a longer PX expiration than the expected refresh time and renew the lock if needed

D. Use GETSET command to overwrite lock without expiration

Solution

1. Step 1: Understand lock expiration vs refresh time

   If lock expires before refresh finishes, another process may acquire lock causing duplicate refresh.

2. Step 2: Choose approach to avoid premature lock expiration

   Setting PX longer than refresh time and renewing lock prevents other processes from acquiring lock too early.

3. Final Answer:

   Set a longer PX expiration than the expected refresh time and renew the lock if needed -> Option C

4. Quick Check:

   Lock expiry > refresh time + renew if needed [OK]

Hint: Lock expiry must cover refresh duration; renew lock if needed [OK]

Common Mistakes:

• Setting too short PX causing multiple refreshes
• Not using PX expiration causing stale locks
• Using GETSET which overwrites lock unsafely