📖 Scenario: You are building a simple product information service that uses Redis as a cache to speed up data retrieval. The main database is slow, so you want to use the cache-aside pattern (also called lazy loading) to first check Redis for product data. If the data is missing, you fetch it from the database and then store it in Redis for future requests.
🎯 Goal: Build a cache-aside system using Redis commands to check for product data in the cache, load it from the database if missing, and update the cache accordingly.
📋 What You'll Learn
Create a Redis hash to store product details with exact keys and values
Set a cache expiration time for product data
Implement a cache-aside retrieval logic using Redis commands
Add a final step to update the cache after loading from the database
💡 Why This Matters
🌍 Real World
Cache-aside is widely used in web applications to improve performance by reducing database load and latency.
💼 Career
Understanding cache-aside with Redis is essential for backend developers working on scalable, high-performance systems.
Progress0 / 4 steps
1
DATA SETUP: Create a Redis hash for product data
Create a Redis hash called product:1001 with these exact fields and values: name set to "Wireless Mouse", price set to 25.99, and stock set to 100.
Redis
Hint
Use the HSET command to create a hash with multiple fields and values.
2
CONFIGURATION: Set cache expiration for the product hash
Set an expiration time of 3600 seconds (1 hour) on the Redis key product:1001 using the correct Redis command.
Redis
Hint
Use the EXPIRE command to set a time-to-live on a key.
3
CORE LOGIC: Implement cache-aside retrieval logic
Write Redis commands to check if the key product:1001 exists using EXISTS. If it does not exist, simulate loading data from the database by creating the hash product:1001 with the same fields and values as before, and set the expiration to 3600 seconds.
Redis
Hint
Use EXISTS to check for the key, then reload and expire if missing.
4
COMPLETION: Update the cache after loading from the database
Add the final Redis command to update the cache key product:1001 with the field stock decreased by 1 using the correct Redis command.
Redis
Hint
Use HINCRBY to decrement the stock field by 1.
Practice
(1/5)
1. What is the main idea behind the Cache-aside (lazy loading) pattern in Redis?
easy
A. Preload all data into cache before any request
B. Load data into cache only when it is requested and missing
C. Update cache only after database changes without reading cache
D. Keep cache and database completely separate without syncing
Solution
Step 1: Understand cache-aside purpose
Cache-aside means data is loaded into cache only when requested and not found in cache.
Step 2: Compare options with definition
Load data into cache only when it is requested and missing matches this lazy loading idea; others describe different caching strategies.
Final Answer:
Load data into cache only when it is requested and missing -> Option B
Quick Check:
Cache-aside = lazy loading on miss [OK]
Hint: Cache-aside loads data only on cache miss [OK]
Common Mistakes:
Thinking cache preloads all data
Confusing cache-aside with write-through caching
Assuming cache and DB never sync
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. EXISTS
B. GET
C. SET
D. DEL
Solution
Step 1: Identify command to check key presence
Redis command EXISTS returns if a key is present in cache.
Step 2: Eliminate other commands
GET retrieves value, SET writes value, DEL deletes key; only EXISTS checks presence.
Final Answer:
EXISTS -> Option A
Quick Check:
Check key presence = EXISTS [OK]
Hint: Use EXISTS to check cache key before GET [OK]
Common Mistakes:
Using GET to check existence (returns nil if missing)
Confusing SET as check command
Using DEL which deletes keys
3. Consider this pseudo-code for cache-aside in Redis:
if not redis.exists(key):
data = db.query(key)
redis.set(key, data)
return redis.get(key)
What will be returned if the key is missing in cache but present in database?
medium
A. Old stale data from cache
B. Null or empty because cache was empty initially
C. An error because key does not exist in cache
D. The data fetched from database and cached
Solution
Step 1: Follow code logic on cache miss
If key missing in Redis, code queries database and sets cache with fresh data.
Step 2: Return cached data after setting
After setting, code returns redis.get(key) which now holds fresh data.
Final Answer:
The data fetched from database and cached -> Option D
Quick Check:
Cache miss triggers DB fetch and cache set [OK]
Hint: Cache miss loads DB data then returns it [OK]
Common Mistakes:
Assuming cache returns empty if initially missing
Expecting error on missing cache key
Thinking cache returns stale data without update
4. You have this cache-aside code snippet:
if redis.get(key) is None:
data = db.query(key)
redis.set(key, data)
return redis.get(key)
But sometimes stale data is returned after DB update. What is the likely bug?
medium
A. Setting cache before querying database
B. Using redis.get instead of redis.exists to check cache
C. Not deleting or updating cache after DB changes
D. Returning data before setting cache
Solution
Step 1: Identify stale data cause
Stale data means cache was not refreshed after DB update.
Step 2: Check cache update strategy
Code only sets cache on miss, but does not invalidate or update cache after DB changes.
Final Answer:
Not deleting or updating cache after DB changes -> Option C
Quick Check:
Cache stale if not refreshed after DB update [OK]
Hint: Always invalidate cache after DB update [OK]
Common Mistakes:
Thinking redis.get check causes stale data
Believing cache sets before DB query fixes stale data
Ignoring cache invalidation on DB writes
5. You want to implement cache-aside with Redis for a user profile service. The database updates user info frequently. Which approach best ensures cache consistency and performance?
hard
A. On DB update, delete cache key; on read, load from DB if cache miss
B. Always write to cache first, then update DB asynchronously
C. Preload all user profiles into cache at service start
D. Never update cache; always read directly from DB
Solution
Step 1: Analyze cache consistency needs
Frequent DB updates require cache invalidation to avoid stale data.
Step 2: Evaluate options for cache-aside pattern
On DB update, delete cache key; on read, load from DB if cache miss deletes cache on DB update, so next read reloads fresh data, matching cache-aside best practice.
Final Answer:
On DB update, delete cache key; on read, load from DB if cache miss -> Option A
Quick Check:
Invalidate cache on update, lazy load on read [OK]
Hint: Delete cache on update, lazy load on read [OK]
Common Mistakes:
Writing cache before DB causes inconsistency
Preloading all data wastes memory and may be stale
Ignoring cache leads to poor performance
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.