Cache-Aside
Problem
- In a railway ticket booking application, a TrainInfo API returns train details like the route, timings, and coach layout from SQL Server. Booking a ticket goes through the same SQL Server.
- When bookings open for a popular train, thousands of users request the details of the same train. Every request runs the same query, even though train details change very rarely.
- SQL Server comes under heavy load. The details pages get slow, and bookings start waiting on a database that is busy answering the same question again and again.
The database drowns in repeated reads it has already answered.
Solution
Cache-Aside
- Check a fast cache (Redis) first.
- On a miss, load the data from SQL Server and store it in the cache with an expiry.
- On an update, remove the cache key so the next read refills it fresh.
The first request for a train fills the cache; the thousands that follow are answered straight from Redis. SQL Server handles only what the cache cannot answer.
If data is read often but changes rarely, cache it. That check-then-fill sequence is cache-aside.
Analogy
Milk in the fridge? Done in seconds. No milk? Drive to the store, then stock the fridge on the way back so the next glass is instant.
The fridge is the cache, the store is the database, and stocking the fridge is on you, never the store.
Cache-aside is checking the fridge before driving to the store.
