Why caching reduces server load in Rest API - Performance Analysis
We want to see how caching affects the work a server does when handling requests.
How does caching change the number of steps the server takes as requests grow?
Analyze the time complexity of the following code snippet.
// Pseudocode for handling API requests with caching
function handleRequest(request) {
if (cache.has(request.key)) {
return cache.get(request.key); // Fast return from cache
} else {
let data = fetchFromDatabase(request.key); // Slow database call
cache.set(request.key, data); // Store in cache
return data;
}
}
This code checks if the requested data is in cache. If yes, it returns quickly. If not, it fetches from the database and saves it in cache.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Checking cache and possibly fetching from database.
- How many times: Once per request, repeated for each incoming request.
As the number of requests grows, the server work depends on cache hits or misses.
| Input Size (requests) | Approx. Operations |
|---|---|
| 10 | Mostly quick cache checks, few database fetches |
| 100 | Many cache checks, some database fetches |
| 1000 | Mostly cache hits, very few database fetches |
Pattern observation: With caching, most requests are fast checks, so work grows slowly even as requests increase.
Time Complexity: O(1)
This means each request takes about the same small amount of time, so the server handles more requests efficiently.
[X] Wrong: "Caching makes the server do less work only sometimes, so it doesn't really help much."
[OK] Correct: Actually, caching means most requests skip slow database calls, so the server workload stays low even with many requests.
Understanding how caching reduces repeated work shows you can improve server speed and handle more users smoothly.
"What if the cache size is very small and often clears? How would the time complexity change?"
Practice
Solution
Step 1: Understand caching purpose
Caching saves copies of data or responses so the server doesn't have to create them again for repeated requests.Step 2: Effect on server load
By serving stored copies, the server avoids extra processing, reducing its workload.Final Answer:
Because it stores copies of responses to serve repeated requests faster -> Option DQuick Check:
Caching reduces server work = D [OK]
- Thinking caching increases server calculations
- Confusing caching with deleting data
- Believing caching forces recalculation every time
Solution
Step 1: Identify caching headers
The HTTP header that controls caching rules is namedCache-Control.Step 2: Verify other headers
Authorizationis for security,Content-Typedefines data format, andUser-Agentidentifies the client.Final Answer:
Cache-Control -> Option AQuick Check:
Cache header = Cache-Control [OK]
- Choosing Authorization for caching
- Confusing Content-Type with caching control
- Selecting User-Agent instead of cache header
1. Client requests resource A (not cached) 2. Server processes and caches response for A 3. Client requests resource A again 4. Server returns cached responseWhat happens at step 4?
Solution
Step 1: Understand caching steps
At first request, server processes and caches the response. On the second request, the cached response is available.Step 2: Behavior at repeated request
Server returns the cached response immediately without reprocessing, speeding up response time.Final Answer:
Server returns the cached response instantly without processing -> Option AQuick Check:
Cached response served = A [OK]
- Thinking server recalculates every time
- Assuming cache is empty on second request
- Believing server delays to check updates
Solution
Step 1: Identify stale data cause
If cached data stays too long, it means the cache expiration or max-age is set too high, so data is not refreshed often.Step 2: Check other options
Cache disabled means no caching, so no stale data. Server not processing or client not sending requests would cause no responses, not stale data.Final Answer:
Cache expiration time is set too high -> Option CQuick Check:
Long cache time = stale data = B [OK]
- Assuming cache is off when stale data appears
- Blaming server or client inactivity
- Ignoring cache expiration settings
Solution
Step 1: Understand caching and freshness tradeoff
Short cache expiration limits stale data time. Conditional requests with ETag let server confirm if data changed before sending full response.Step 2: Evaluate other options
Disabling caching increases load. Indefinite caching causes stale data. Caching only errors doesn't reduce load effectively.Final Answer:
Set a short cache expiration and use conditional requests with ETag headers -> Option BQuick Check:
Short cache + ETag = freshness + load reduction = C [OK]
- Disabling caching to fix freshness
- Caching forever without validation
- Caching only error responses
Ready to prove it?
Pass the test and this pattern moves unknown
