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.