Cache invalidation strategies in Rest API - Step-by-Step Execution

Concept Flow - Cache invalidation strategies

Client requests data

↓

Check cache for data

↓

End

This flow shows how a system checks cache before fetching fresh data and how cache invalidation triggers update the cache.

Execution Sample

Rest API

GET /data
if cache.has(data):
  return cache.get(data)
else:
  fresh = fetch_from_server()
  cache.set(data, fresh)
  return fresh

This code checks if data is in cache; if yes, returns it; if no, fetches fresh data, updates cache, then returns it.

Execution Table

Step	Action	Cache State	Data Returned	Cache Invalidation Trigger
1	Client requests /data	Empty	None	None
2	Check cache for data	Empty	None	None
3	Cache miss, fetch fresh data	Empty	None	None
4	Store fresh data in cache	Data stored	None	None
5	Return fresh data to client	Data stored	Fresh data	None
6	Later client requests /data	Data stored	None	None
7	Check cache for data	Data stored	Cached data	None
8	Return cached data to client	Data stored	Cached data	None
9	Cache expiry time reached	Data stored	None	Time-based expiry
10	Invalidate cache	Empty	None	Cache cleared
11	Next client request /data	Empty	None	None
12	Cache miss, fetch fresh data	Empty	None	None
13	Store fresh data in cache	Data stored	None	None
14	Return fresh data to client	Data stored	Fresh data	None

💡 Execution stops after fresh data is returned and cache is updated or invalidated.

Variable Tracker

Variable	Start	After Step 4	After Step 8	After Step 10	After Step 13	Final
cache	Empty	Data stored	Data stored	Empty	Data stored	Data stored
data returned	None	None	Cached data	None	None	Fresh data

Key Moments - 3 Insights

Why does the system fetch fresh data even though cache exists sometimes?

Because the cache can expire or be invalidated (see steps 9 and 10 in execution_table), so the system must fetch fresh data to keep information up to date.

What happens if the cache is empty when a client requests data?

The system fetches fresh data from the server, stores it in cache, then returns it (see steps 3, 4, and 5).

How does time-based expiry affect cache data?

When the expiry time is reached (step 9), the cache is cleared (step 10), forcing fresh data to be fetched on the next request.

Visual Quiz - 3 Questions

Look at the execution_table, what is the cache state after step 4?

A Empty

B Data stored

C Cache cleared

D Unknown

💡 Hint

Refer to the 'Cache State' column at step 4 in execution_table.

At which step does the cache get invalidated due to time expiry?

A Step 8

B Step 9

C Step 10

D Step 12

💡 Hint

Check the 'Cache Invalidation Trigger' column around steps 9 and 10.

If the cache never expires, what would happen at step 11?

A Cache miss, fetch fresh data

B Return cached data

C Invalidate cache

D Store fresh data

💡 Hint

Look at step 7 and 8 where cache is used if present.

Concept Snapshot

Cache Invalidation Strategies:
- Check cache before fetching data
- If cache miss, fetch fresh data and update cache
- Invalidate cache by:
  * Time-based expiry
  * Manual purge
  * Event-based triggers
- Keeps data fresh and reduces server load

Full Transcript

This visual execution shows how cache invalidation strategies work in a REST API context. When a client requests data, the system first checks if the data is in cache. If yes, it returns cached data immediately. If not, it fetches fresh data from the server, stores it in cache, and returns it. Cache invalidation can happen due to time expiry, manual clearing, or events that signal data changes. When cache is invalidated, the next request triggers fresh data fetching again. This process helps keep data fresh while improving performance by reducing unnecessary server calls.

Practice

1. Which cache invalidation strategy automatically removes cached data after a set period of time?

easy

A. Manual invalidation

B. Event-based invalidation

C. Time-based invalidation

D. Versioning invalidation

Solution

1. Step 1: Understand time-based invalidation

   Time-based invalidation removes cached data after a fixed time, ensuring data freshness automatically.

2. Step 2: Compare with other strategies

   Manual invalidation requires user action, event-based depends on data changes, and versioning uses data versions.

3. Final Answer:

   Time-based invalidation -> Option C

4. Quick Check:

   Automatic removal after time = Time-based invalidation [OK]

Hint: Time-based means cache expires after set time [OK]

Common Mistakes:

• Confusing manual with automatic removal
• Thinking event-based triggers on time
• Mixing versioning with time expiry

2. Which of the following is the correct way to manually invalidate a cache entry in a REST API?

easy

A. Send a PUT request to update cached data

B. Send a GET request to the cache endpoint

C. Send a POST request to retrieve cached data

D. Send a DELETE request to the cache endpoint

Solution

1. Step 1: Identify HTTP method for deletion

   DELETE requests are used to remove resources, including cache entries.

2. Step 2: Understand other methods

   GET retrieves data, POST creates, and PUT updates; none remove cache.

3. Final Answer:

   Send a DELETE request to the cache endpoint -> Option D

4. Quick Check:

   DELETE removes cache entry manually [OK]

Hint: DELETE method removes resources like cache entries [OK]

Common Mistakes:

• Using GET to remove cache
• Confusing POST with deletion
• Thinking PUT deletes cache

3. Consider this pseudo-code for event-based cache invalidation:

if (dataChangedEvent) {
  invalidateCache(key);
}
return getCachedData(key);

What will happen if dataChangedEvent is true?

medium

A. Cache is invalidated and fresh data is fetched next time

B. Cache remains unchanged and stale data is returned

C. Cache is updated without invalidation

D. An error occurs because cache cannot be invalidated

Solution

1. Step 1: Analyze the condition

   If dataChangedEvent is true, invalidateCache(key) runs, removing cached data.

2. Step 2: Understand cache behavior after invalidation

   After invalidation, next data fetch will get fresh data, not stale cache.

3. Final Answer:

   Cache is invalidated and fresh data is fetched next time -> Option A

4. Quick Check:

   Event triggers invalidation = fresh data next fetch [OK]

Hint: Event true means cache cleared for fresh data [OK]

Common Mistakes:

• Assuming cache stays after invalidation
• Thinking cache updates automatically
• Believing invalidation causes errors

4. You have this code snippet for versioning cache invalidation:

cache = { 'v1': data1 }
function getData(version) {
  return cache[version];
}

// Later
cache['v2'] = newData;

What is the main bug if the client still requests v1 after update?

medium

A. Cache throws an error because version key is missing

B. Client gets stale data because old version is still cached

C. Cache automatically updates old version to new data

D. Client cannot access any cached data

Solution

1. Step 1: Understand versioning cache behavior

   Old version 'v1' remains in cache, so requests for it get stale data.

2. Step 2: Identify bug impact

   Client requesting 'v1' does not see 'v2' data, causing stale responses.

3. Final Answer:

   Client gets stale data because old version is still cached -> Option B

4. Quick Check:

   Old version key returns stale data [OK]

Hint: Old version keys keep stale data unless removed [OK]

Common Mistakes:

• Assuming cache auto-updates old versions
• Expecting errors on missing keys
• Thinking client loses all cache access

5. You want to design a cache invalidation strategy for a REST API where data changes frequently but must stay fresh within 5 minutes. Which combined strategy is best?

hard

A. Use time-based invalidation with 5-minute expiry plus event-based invalidation on data changes

B. Use manual invalidation only, requiring user to clear cache

C. Use versioning only without time limits

D. Use time-based invalidation with 1-hour expiry only

Solution

1. Step 1: Analyze freshness requirement

   Data must be fresh within 5 minutes, so time-based expiry should be 5 minutes or less.

2. Step 2: Combine with event-based invalidation

   Event-based invalidation clears cache immediately on data changes, improving freshness.

3. Step 3: Evaluate other options

   Manual invalidation is slow, versioning alone may keep stale data, and 1-hour expiry is too long.

4. Final Answer:

   Use time-based invalidation with 5-minute expiry plus event-based invalidation on data changes -> Option A

5. Quick Check:

   Combine time and event for fresh cache [OK]

Hint: Combine time and event for best freshness [OK]

Common Mistakes:

• Relying only on manual invalidation
• Using too long expiry times
• Ignoring event triggers for changes