Cache stampede prevention in Redis - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to set a cache key with an expiration time to prevent stale data.

Redis

redis.set('user:123', user_data, ex=[1])

Drag options to blanks, or click blank then click option'

A-1

BNone

C3600

D0

Attempts:

3 left

💡 Hint

Common Mistakes

Using 0 or negative values disables expiration, causing stale cache.

Setting an expiration time (in seconds) like 3600 ensures the cache expires after one hour, helping prevent stale data.

2fill in blank

medium

Complete the code to acquire a lock key before regenerating cache to prevent cache stampede.

Redis

if redis.setnx('lock:user:123', '1'):
    redis.expire('lock:user:123', [1])
    # regenerate cache

Drag options to blanks, or click blank then click option'

A10

B-5

CNone

D0

Attempts:

3 left

💡 Hint

Common Mistakes

Not setting expiration can cause deadlocks.

Setting a short expiration (like 10 seconds) on the lock prevents deadlocks if the process crashes.

3fill in blank

hard

Fix the error in the code that tries to get cached data and falls back to regeneration if missing.

Redis

data = redis.get('user:123')
if data is [1]:
    # regenerate cache

Drag options to blanks, or click blank then click option'

AFalse

B''

C0

DNone

Attempts:

3 left

💡 Hint

Common Mistakes

Checking for False or empty string causes incorrect cache miss detection.

Redis returns None if the key does not exist, so checking for None detects cache miss.

4fill in blank

hard

Fill both blanks to implement a safe cache regeneration with lock and expiration.

Redis

if redis.setnx('lock:user:123', '1'):
    redis.expire('lock:user:123', [1])
    data = regenerate_data()
    redis.set('user:123', data, ex=[2])
    redis.delete('lock:user:123')

Drag options to blanks, or click blank then click option'

A10

B3600

C60

DNone

Attempts:

3 left

💡 Hint

Common Mistakes

Setting lock expiration too long causes blocking.

Setting cache expiration too short causes frequent regeneration.

Lock expiration is short (10 seconds) to avoid deadlocks. Cache expiration is longer (3600 seconds) to keep data fresh.

5fill in blank

hard

Fill all three blanks to implement cache stampede prevention with lock check, regeneration, and fallback.

Redis

data = redis.get('user:123')
if data is [1]:
    if redis.setnx('lock:user:123', '1'):
        redis.expire('lock:user:123', [2])
        data = regenerate_data()
        redis.set('user:123', data, ex=[3])
        redis.delete('lock:user:123')
    else:
        time.sleep(0.1)
        data = redis.get('user:123')

Drag options to blanks, or click blank then click option'

ANone

B10

C3600

DFalse

Attempts:

3 left

💡 Hint

Common Mistakes

Using False instead of None for cache miss.

Not setting lock expiration.

Setting cache expiration too short.

Check for None to detect cache miss. Lock expiration is short (10 seconds). Cache expiration is longer (3600 seconds) to keep data fresh.

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