Cache-aside pattern in Redis

Introduction

The cache-aside pattern helps speed up data access by storing frequently used data in a fast cache. It keeps the cache and database in sync by loading data into the cache only when needed.

When you want to reduce slow database reads by using a fast cache.

When your application reads the same data many times but updates it less often.

When you want to keep your cache updated only with data that is actually requested.

When you want to avoid stale data by loading fresh data from the database on cache misses.

When you want simple control over when data is cached and when it is refreshed.

Syntax

Redis

1. Check if data is in cache (GET key)
2. If data is found, return it
3. If not found, load data from database
4. Store data in cache (SET key value EX expiration)
5. Return the data

This pattern requires your application to handle cache misses by loading data from the database.

Cache entries should have expiration times to avoid stale data.

Examples

Try to get user data from cache. If missing, get from database and save in cache for 1 hour.

Redis

GET user:123
// If null, query database for user 123
SET user:123 "{...user data...}" EX 3600

Cache product info for 30 minutes after loading from database on cache miss.

Redis

GET product:456
// If cache miss, fetch product 456 from DB
SET product:456 "{...product data...}" EX 1800

Sample Program

First, we try to get item 101 from cache but it is missing. Then we simulate loading from the database and store it in cache with a 5-minute expiration. Finally, we get the cached item successfully.

Redis

127.0.0.1:6379> GET item:101
(nil)
127.0.0.1:6379> // Cache miss, load from DB (simulated)
127.0.0.1:6379> SET item:101 "{\"name\": \"Pen\", \"price\": 1.5}" EX 300
OK
127.0.0.1:6379> GET item:101
"{\"name\": \"Pen\", \"price\": 1.5}"

Important Notes

Always handle the case when cache returns null or missing data.

Set expiration times on cached data to prevent stale information.

Write operations should update the database first, then invalidate or update the cache.

Summary

The cache-aside pattern loads data into cache only on demand.

It helps improve performance by reducing database load.

It requires your application to manage cache misses and updates.

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