Expiration-based caching in Rest API - Time & Space Complexity
When using expiration-based caching in a REST API, we want to know how the time to handle requests changes as more data is cached or expires.
We ask: How does the caching process affect the speed of serving requests as cache size grows?
Analyze the time complexity of the following code snippet.
cache = {}
function getData(key) {
if (key in cache) {
if (cache[key].expiry > currentTime()) {
return cache[key].value
} else {
delete cache[key]
}
}
let data = fetchFromDatabase(key)
cache[key] = { value: data, expiry: currentTime() + 300 }
return data
}
This code checks if data is in cache and not expired. If expired or missing, it fetches fresh data and updates the cache.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Checking if the key exists and if the cached item is expired.
- How many times: This check happens once per request.
As the number of cached items grows, each request still checks only one key.
| Input Size (number of cached keys) | Approx. Operations per Request |
|---|---|
| 10 | 1 key check + possible fetch |
| 100 | 1 key check + possible fetch |
| 1000 | 1 key check + possible fetch |
Pattern observation: The time to check cache does not grow with cache size because it uses direct key lookup.
Time Complexity: O(1)
This means each request takes about the same time to check the cache, no matter how many items are stored.
[X] Wrong: "Checking if a cached item expired takes longer as the cache grows."
[OK] Correct: The cache uses direct key lookup, so expiration check is done only on the requested item, not all cached items.
Understanding how caching affects request time helps you design fast APIs and shows you can think about performance clearly.
"What if the cache used a list instead of a key-value store? How would the time complexity change?"
Practice
Cache-Control: max-age header do in expiration-based caching?Solution
Step 1: Understand the role of Cache-Control header
The Cache-Control header controls caching behavior for HTTP responses.Step 2: Identify the meaning of max-age directive
The max-age directive specifies the time in seconds that the response is considered fresh and can be served from cache.Final Answer:
It sets how long the cached data is considered fresh. -> Option CQuick Check:
max-age = cache freshness duration [OK]
- Confusing max-age with disabling cache
- Thinking max-age deletes cache immediately
- Assuming max-age forces fresh fetch every time
Solution
Step 1: Recall correct Cache-Control syntax
The Cache-Control header uses directives separated by commas, with max-age specified as max-age=seconds.Step 2: Compare options to correct syntax
Only Cache-Control: max-age=300 uses the correct format: max-age=300.Final Answer:
Cache-Control: max-age=300 -> Option BQuick Check:
Correct header syntax = max-age=seconds [OK]
- Using colon instead of equal sign
- Using incorrect directive names like expire or timeout
- Adding spaces inside the directive
Cache-Control: max-age=10What will happen if a client requests the same resource 5 seconds later?
Solution
Step 1: Understand max-age meaning
max-age=10 means the cached data is fresh for 10 seconds after the first fetch.Step 2: Check time elapsed since caching
5 seconds is less than 10 seconds, so cache is still fresh and valid.Final Answer:
The client will use the cached response without contacting the server. -> Option AQuick Check:
Elapsed time < max-age = use cache [OK]
- Assuming cache expires immediately
- Thinking client always fetches new data
- Confusing max-age with cache invalidation
Cache-Control: max-age=60 but clients still fetch new data every time. What is the likely mistake?Solution
Step 1: Check for conflicting headers
If the server sends a no-cache directive, it forces clients to revalidate or fetch fresh data despite max-age.Step 2: Understand max-age units and client support
max-age is in seconds, and most clients support caching headers, so these are unlikely causes.Final Answer:
The server is sending no-cache header overriding max-age. -> Option DQuick Check:
no-cache overrides max-age [OK]
- Confusing seconds with milliseconds for max-age
- Blaming client support without checking headers
- Assuming URL format affects caching
Solution
Step 1: Understand caching for 5 minutes
max-age=300 sets cache freshness for 300 seconds (5 minutes).Step 2: Ensure fresh data after expiration
must-revalidate forces clients to check with server after max-age expires before using cached data.Step 3: Evaluate other options
no-store disables caching, no-cache forces revalidation every time, max-age=0 means no caching.Final Answer:
Cache-Control: max-age=300, must-revalidate -> Option AQuick Check:
max-age + must-revalidate = cache then fresh after expiry [OK]
- Using no-store disables caching completely
- Using no-cache forces revalidation every request
- Setting max-age=0 disables caching
Ready to prove it?
Pass the test and this pattern moves unknown
