Cache-aside pattern in Redis - Step-by-Step Execution

Concept Flow - Cache-aside pattern

Request data

↓

Check cache

↓

Return

↓

Store in cache

↓

Return

The cache-aside pattern first checks the cache for data. If found (hit), it returns it. If not (miss), it fetches from the database, stores it in cache, then returns it.

Execution Sample

Redis

1. Check cache for key 'user:1'
2. If found, return cached data
3. Else, query DB for user 1
4. Store DB result in cache
5. Return data

This simulates a cache-aside pattern fetching user data by first checking Redis cache, then DB if needed.

Execution Table

Step	Action	Cache Check Result	DB Query	Cache Update	Return Value
1	Check cache for 'user:1'	Miss	No	No	No
2	Query DB for 'user:1'	N/A	Yes	No	No
3	Store DB result in cache	N/A	N/A	Yes	No
4	Return data to caller	N/A	N/A	N/A	User data from DB
5	Next request: Check cache for 'user:1'	Hit	No	No	User data from cache

💡 Execution stops after returning data; subsequent requests hit cache directly.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5
cache['user:1']	empty	empty	empty	user data	user data	user data
db_result	none	none	user data	user data	user data	user data
return_value	none	none	none	none	user data	user data

Key Moments - 3 Insights

Why do we check the cache before querying the database?

Checking the cache first (Step 1) avoids unnecessary database queries, improving speed and reducing load, as shown in the execution_table where a cache hit skips DB query.

What happens when the cache misses the data?

On a cache miss (Step 1), the system queries the database (Step 2), then stores the result in cache (Step 3) before returning it (Step 4), ensuring future requests hit the cache.

Why do subsequent requests return data from cache?

After storing data in cache (Step 3), the cache holds the data for future requests, so the next check (Step 5) hits cache and returns data immediately without DB access.

Visual Quiz - 3 Questions

Look at the execution_table, what is the cache check result at Step 5?

A Hit

B Miss

C Empty

D Error

💡 Hint

Refer to the 'Cache Check Result' column at Step 5 in the execution_table.

At which step does the database get queried?

A Step 1

B Step 2

C Step 3

D Step 5

💡 Hint

Check the 'DB Query' column in the execution_table to find when it is 'Yes'.

If the cache already has the data, which steps are skipped?

A Steps 3 and 5

B Steps 1 and 4

C Steps 2 and 3

D Steps 1 and 2

💡 Hint

Look at the execution_table rows where cache check is 'Hit' and see which actions are 'No'.

Concept Snapshot

Cache-aside pattern:
1. Check cache for data.
2. If hit, return cached data.
3. If miss, query DB.
4. Store DB result in cache.
5. Return data.
Improves performance by reducing DB load.

Full Transcript

The cache-aside pattern works by first checking the cache for requested data. If the data is found (cache hit), it returns immediately, avoiding a database query. If the data is not found (cache miss), the system queries the database, stores the result in the cache for future use, and then returns the data. This pattern helps improve performance by reducing database load and speeding up data retrieval. The execution table shows each step: checking cache, querying DB if needed, updating cache, and returning data. Variables like cache content and return values change accordingly. Key moments include understanding why cache is checked first, what happens on a miss, and why subsequent requests hit the cache. The visual quiz tests understanding of these steps and their order.

Practice

1. What is the main idea behind the cache-aside pattern in Redis?

easy

A. Automatically update cache whenever the database changes without application intervention

B. Load data into cache only when the application requests it and cache misses occur

C. Preload all data into cache before any application requests

D. Use cache only for temporary data that does not come from the database

Solution

1. Step 1: Understand cache-aside pattern basics

   The cache-aside pattern means the application loads data into cache only when it is needed, not before.

2. Step 2: Compare options with this concept

   Load data into cache only when the application requests it and cache misses occur matches this idea exactly, while others describe different caching strategies.

3. Final Answer:

   Load data into cache only when the application requests it and cache misses occur -> Option B

4. Quick Check:

   Cache-aside = Load on demand [OK]

Hint: Cache-aside means load cache only on demand [OK]

Common Mistakes:

• Thinking cache is preloaded with all data
• Assuming cache updates automatically without app logic
• Confusing cache-aside with write-through caching

2. Which Redis command is typically used to check if a key exists in cache before loading from the database in cache-aside pattern?

easy

A. DEL

B. GET

C. SET

D. EXISTS

Solution

1. Step 1: Identify command to check key presence

   In Redis, EXISTS checks if a key is present in cache.

2. Step 2: Match commands with their purpose

   GET retrieves value, SET stores value, DEL deletes key. Only EXISTS checks presence.

3. Final Answer:

   EXISTS -> Option D

4. Quick Check:

   Check key presence = EXISTS [OK]

Hint: Use EXISTS to check if cache key is present [OK]

Common Mistakes:

• Using GET to check existence (GET returns null if missing)
• Confusing SET with checking commands
• Using DEL which deletes keys

3. Consider this Redis cache-aside pseudocode:

if not redis.exists('user:123'):
    data = db.query('SELECT * FROM users WHERE id=123')
    redis.set('user:123', data)
else:
    data = redis.get('user:123')

What happens if the key user:123 is missing in Redis?

medium

A. Redis automatically loads data from database

B. Data is fetched from Redis but will be empty

C. Data is fetched from the database and stored in Redis cache

D. An error occurs because key does not exist

Solution

1. Step 1: Analyze the if condition for cache miss

   If user:123 does not exist in Redis, the code queries the database for data.

2. Step 2: Understand cache population after miss

   After fetching from database, it stores the data in Redis with set for future requests.

3. Final Answer:

   Data is fetched from the database and stored in Redis cache -> Option C

4. Quick Check:

   Cache miss triggers DB fetch and cache store [OK]

Hint: Cache miss means fetch DB and store in cache [OK]

Common Mistakes:

• Assuming Redis auto-loads data from DB
• Expecting error on missing key
• Thinking Redis returns empty data silently

4. You have this cache-aside code snippet in Redis:

if redis.get('product:456') is None:
    data = db.query('SELECT * FROM products WHERE id=456')
    redis.set('product:456', data)
else:
    data = redis.get('product:456')

But the cache never updates even after database changes. What is the likely problem?

medium

A. The cache is never invalidated or updated after DB changes

B. The Redis GET command is incorrect

C. The database query syntax is wrong

D. The key name 'product:456' is invalid in Redis

Solution

1. Step 1: Identify cache update mechanism

   The code only sets cache if key is missing but does not update or invalidate cache after DB changes.

2. Step 2: Understand cache staleness cause

   Without cache invalidation or update logic after DB writes, cache remains stale and does not reflect DB changes.

3. Final Answer:

   The cache is never invalidated or updated after DB changes -> Option A

4. Quick Check:

   Cache stale if no invalidation after DB update [OK]

Hint: Cache must be invalidated after DB updates [OK]

Common Mistakes:

• Assuming GET command causes update
• Blaming DB query syntax without evidence
• Thinking Redis keys are invalid without reason

5. You want to implement cache-aside pattern in Redis for a user profile service. Which approach correctly handles cache misses and updates when user data changes?

1. On read: check cache, if miss fetch DB and set cache
2. On write: update DB, then delete cache key to force reload on next read

Why is deleting the cache key after DB update preferred over updating cache directly?

hard

A. Deleting cache key avoids race conditions and stale data issues

B. Updating cache directly is impossible in Redis

C. Deleting cache key improves Redis memory usage drastically

D. Updating cache directly causes Redis to crash

Solution

1. Step 1: Understand cache update strategies

   Deleting cache key after DB update forces next read to reload fresh data, avoiding stale cache.

2. Step 2: Recognize race condition prevention

   Direct cache update risks race conditions if multiple writes/read happen concurrently; deleting key is safer.

3. Final Answer:

   Deleting cache key avoids race conditions and stale data issues -> Option A

4. Quick Check:

   Delete cache key after DB write to avoid stale data [OK]

Hint: Delete cache key after DB update to avoid stale data [OK]

Common Mistakes:

• Thinking Redis cannot update cache values
• Believing direct cache update is always better
• Assuming deleting cache key crashes Redis