Cache-aside (lazy loading) deep dive in Redis - Step-by-Step Execution

Concept Flow - Cache-aside (lazy loading) deep dive

Request data

↓

Check cache

↓

Return

↓

Store in cache

↓

Return

When data is requested, first check the cache. If found (hit), return it. If not (miss), load from database, store in cache, then return.

Execution Sample

Redis

1. Request key 'user:1'
2. Check Redis cache
3. If miss, query DB
4. Store DB result in Redis
5. Return data

This simulates a cache-aside pattern where data is lazily loaded into cache on a miss.

Execution Table

Step	Action	Cache State	DB Query	Result Returned
1	Request 'user:1'	{}	No	No data yet
2	Check cache for 'user:1'	{}	No	Cache miss
3	Query DB for 'user:1'	{}	Yes	{id:1, name:'Alice'}
4	Store '{id:1, name:"Alice"}' in cache	{"user:1": "{id:1, name:\"Alice\"}"}	No	No
5	Return data from cache	{"user:1": "{id:1, name:\"Alice\"}"}	No	{id:1, name:'Alice'}
6	Request 'user:1' again	{"user:1": "{id:1, name:\"Alice\"}"}	No	No
7	Check cache for 'user:1'	{"user:1": "{id:1, name:\"Alice\"}"}	No	Cache hit
8	Return data from cache	{"user:1": "{id:1, name:\"Alice\"}"}	No	{id:1, name:'Alice'}

💡 After cache is populated, subsequent requests hit cache and avoid DB queries.

Variable Tracker

Variable	Start	After Step 4	After Step 8
Cache	{}	{"user:1": "{id:1, name:\"Alice\"}"}	{"user:1": "{id:1, name:\"Alice\"}"}
DB Query Count	0	1	1
Returned Data	None	{id:1, name:'Alice'}	{id:1, name:'Alice'}

Key Moments - 3 Insights

Why do we query the database only once?

Because after the first miss, the data is stored in cache (see Step 4), so subsequent requests find it in cache (Step 7), avoiding DB queries.

What happens if the cache has the data?

The system returns data directly from cache (Step 8) without querying the database, improving speed.

Why is the cache empty at the start?

Cache starts empty because data is loaded lazily only when requested and missing in cache (Step 2).

Visual Quiz - 3 Questions

Look at the execution table, what is the cache state after Step 4?

A {}

B Cache miss

C {"user:1": "{id:1, name:\"Alice\"}"}

D No cache

💡 Hint

Check the 'Cache State' column at Step 4 in the execution_table.

At which step does the database get queried?

A Step 3

B Step 2

C Step 5

D Step 7

💡 Hint

Look at the 'DB Query' column in the execution_table to find when it says 'Yes'.

If the cache was pre-populated, which step would be skipped?

A Step 1 (Request data)

B Step 3 (Query DB)

C Step 4 (Store in cache)

D Step 8 (Return data)

💡 Hint

Refer to the execution_table steps where DB query happens only on cache miss.

Concept Snapshot

Cache-aside (lazy loading) pattern:
- On data request, check cache first.
- If cache miss, load from DB.
- Store DB result in cache.
- Return data from cache.
- Subsequent requests hit cache, avoiding DB.
- Improves performance by reducing DB load.

Full Transcript

Cache-aside or lazy loading means when you ask for data, the system first looks in the cache. If the data is there, it returns it quickly. If not, it goes to the database, gets the data, saves it in the cache, then returns it. This way, the database is only asked when needed, and the cache keeps data ready for next time. The execution table shows the steps: request, cache check, DB query on miss, cache store, and return. Variables like cache content and DB query count change accordingly. This pattern helps speed up data access and reduce database load.

Practice

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

1. Step 1: Understand cache-aside purpose

   Cache-aside means data is loaded into cache only when requested and not found in cache.

2. 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.

3. Final Answer:

   Load data into cache only when it is requested and missing -> Option B

4. 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

1. Step 1: Identify command to check key presence

   Redis command EXISTS returns if a key is present in cache.

2. Step 2: Eliminate other commands

   GET retrieves value, SET writes value, DEL deletes key; only EXISTS checks presence.

3. Final Answer:

   EXISTS -> Option A

4. 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

1. Step 1: Follow code logic on cache miss

   If key missing in Redis, code queries database and sets cache with fresh data.

2. Step 2: Return cached data after setting

   After setting, code returns redis.get(key) which now holds fresh data.

3. Final Answer:

   The data fetched from database and cached -> Option D

4. 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

1. Step 1: Identify stale data cause

   Stale data means cache was not refreshed after DB update.

2. Step 2: Check cache update strategy

   Code only sets cache on miss, but does not invalidate or update cache after DB changes.

3. Final Answer:

   Not deleting or updating cache after DB changes -> Option C

4. 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

1. Step 1: Analyze cache consistency needs

   Frequent DB updates require cache invalidation to avoid stale data.

2. 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.

3. Final Answer:

   On DB update, delete cache key; on read, load from DB if cache miss -> Option A

4. 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