An interviewer asked: "What caching strategy does your app use?"
The candidate said: "We use Redis."
Interviewer: "That's a tool. I asked for a strategy."
Silence. Interview over. 😶
Here's every caching strategy broken down 👇
🧠 𝗪𝗵𝗮𝘁 𝗶𝘀 𝗖𝗮𝗰𝗵𝗶𝗻𝗴?
👉 Storing data temporarily so future requests are served faster
👉 Avoids hitting the original source — DB, API, server — every time
👉 Wrong strategy = stale data, crashes, data loss
Without cache: User → Server → Database (slow 🐢)
With cache: User → Cache (fast ⚡)
↓ miss only
Database
✔ Reduces latency
✔ Reduces database load
✔ Scales better under traffic
⚡ 1️⃣ 𝗖𝗮𝗰𝗵𝗲-𝗔𝘀𝗶𝗱𝗲 (𝗟𝗮𝘇𝘆 𝗟𝗼𝗮𝗱𝗶𝗻𝗴)
👉 App checks cache first. Miss → fetch DB → store in cache.
async function getUser(id) {
// Step 1 — check cache
const cached = await redis.get(`user:${id}`);
if (cached) return JSON.parse(cached);
// Step 2 — cache miss, hit DB
const user = await db.findUser(id);
// Step 3 — store in cache for next time
await redis.set(`user:${id}`, JSON.stringify(user), 'EX', 3600);
return user;
}
✔ Only caches what's actually requested
✔ Cache failure doesn't break the app
❌ First request always slow — cold cache
❌ Risk of stale data between TTL cycles
🎯 2️⃣ 𝗪𝗿𝗶𝘁𝗲-𝗧𝗵𝗿𝗼𝘂𝗴𝗵
👉 Every write goes to cache AND database simultaneously
async function updateUser(id, data) {
// Write to DB and cache together
await db.updateUser(id, data);
await redis.set(`user:${id}`, JSON.stringify(data), 'EX', 3600);
}
✔ Cache always in sync with DB
✔ No stale reads after writes
❌ Write latency increases — two writes every time
❌ Cache fills with data that may never be read
👉 Best for: Read-heavy apps where freshness is critical
🚀 3️⃣ 𝗪𝗿𝗶𝘁𝗲-𝗕𝗲𝗵𝗶𝗻𝗱 (𝗪𝗿𝗶𝘁𝗲-𝗕𝗮𝗰𝗸)
👉 Write to cache instantly. Sync to DB asynchronously later.
User writes → Cache ✅ (instant response)
↓ async worker (batched every 5s)
Database 🕐 (eventually consistent)
async function updateScore(userId, score) {
// Instant write to cache
await redis.set(`score:${userId}`, score);
// Add to queue — worker syncs to DB later
await queue.add('syncScore', { userId, score });
}
✔ Blazing fast write performance
✔ Reduces DB write load — batch updates
❌ Risk of data loss if cache crashes before sync
❌ Complex to implement correctly
👉 Best for: Leaderboards, analytics, gaming, counters
🔄 4️⃣ 𝗥𝗲𝗮𝗱-𝗧𝗵𝗿𝗼𝘂𝗴𝗵
👉 App only talks to cache. Cache fetches from DB on miss.
App → Cache → (hit) → App ✅
App → Cache → (miss) → DB → Cache populates → App ✅
// App never touches DB directly
const user = await cacheProvider.get(`user:${id}`);
// Cache provider handles DB fetch internally on miss
✔ App logic stays clean — zero cache handling code
✔ Cache always populated after first request
❌ Cache provider must support read-through natively
❌ First request latency still exists
👉 Best for: Managed caches — AWS ElastiCache, DAX
⏰ 5️⃣ 𝗥𝗲𝗳𝗿𝗲𝘀𝗵-𝗔𝗵𝗲𝗮𝗱
👉 Cache proactively refreshes data before TTL expires
TTL = 60s
At 45s → background job pre-fetches fresh data
At 60s → cache already has new data ✅ zero miss latency
async function getWithRefreshAhead(key, fetchFn, ttl = 60) {
const cached = await redis.get(key);
const ttlRemaining = await redis.ttl(key);
// Refresh when 75% of TTL has passed
if (ttlRemaining < ttl * 0.25) {
fetchFn().then(data =>
redis.set(key, JSON.stringify(data), 'EX', ttl)
);
}
return cached ? JSON.parse(cached) : fetchFn();
}
✔ No latency spikes on cache expiry
✔ Always serving warm data
❌ May refresh data that's never requested — wasted compute
👉 Best for: Homepages, dashboards, trending feeds
🔑 6️⃣ 𝗖𝗮𝗰𝗵𝗲 𝗜𝗻𝘃𝗮𝗹𝗶𝗱𝗮𝘁𝗶𝗼𝗻 𝗦𝘁𝗿𝗮𝘁𝗲𝗴𝗶𝗲𝘀
👉 Knowing WHEN to clear cache is as important as caching itself
// TTL — expire after fixed time
await redis.set('user:1', data, 'EX', 3600); // expires in 1hr
// Event-based — clear on data change
async function updateUser(id, data) {
await db.updateUser(id, data);
await redis.del(`user:${id}`); // invalidate immediately
}
// Cache versioning — bump version on deploy
const key = `user:${id}:v2`; // old v1 cache naturally expires
✔ TTL — simple, automatic
✔ Event-based — precise, immediate
✔ Versioning — safe for deployments
🚨 𝗖𝗮𝗰𝗵𝗲 𝗣𝗿𝗼𝗯𝗹𝗲𝗺𝘀 𝗬𝗼𝘂 𝗠𝘂𝘀𝘁 𝗞𝗻𝗼𝘄
// Cache Stampede — TTL expires, 1000 users hit DB together
// Fix: mutex lock — only one request rebuilds cache
const lock = await redis.set('lock:user:1', 1, 'NX', 'EX', 5);
if (lock) { /* fetch DB and repopulate */ }
else { /* wait and retry */ }
// Cache Penetration — requests for non-existent data bypass cache
// Fix: cache null values too
await redis.set(`user:${id}`, 'NULL', 'EX', 60);
// Cache Avalanche — all keys expire at same time
// Fix: add random jitter to TTL
const ttl = 3600 + Math.floor(Math.random() * 300);
⚛️ 𝗙𝗿𝗼𝗻𝘁𝗲𝗻𝗱 𝗖𝗮𝗰𝗵𝗶𝗻𝗴 (𝗥𝗲𝗮𝗰𝘁)
// React Query — cache-aside in the frontend
const { data } = useQuery({
queryKey: ['user', id],
queryFn: () => fetch(`/api/user/${id}`),
staleTime: 5 * 60 * 1000, // fresh for 5 mins
cacheTime: 10 * 60 * 1000, // keep in memory for 10 mins
});
✔ staleTime — how long data is considered fresh
✔ cacheTime — how long unused data stays in memory
✔ React Query implements cache-aside pattern automatically
🚨 𝗖𝗼𝗺𝗺𝗼𝗻 𝗠𝗶𝘀𝘁𝗮𝗸𝗲𝘀
❌ Caching without a TTL — stale data lives forever
❌ Not handling cache miss gracefully — app crashes
❌ Caching user-specific data globally — data leaks
❌ Using Write-Behind without a reliable queue
❌ Ignoring cache stampede on high-traffic TTL expiry
💡 𝗦𝗲𝗻𝗶𝗼𝗿-𝗟𝗲𝘃𝗲𝗹 𝗜𝗻𝘀𝗶𝗴𝗵𝘁
There are only two hard problems in computer science: cache invalidation and naming things.
Choosing the wrong strategy doesn't slow your app — it silently corrupts it.
🎯 𝗜𝗻𝘁𝗲𝗿𝘃𝗶𝗲𝘄 𝗢𝗻𝗲-𝗟𝗶𝗻𝗲𝗿
Caching strategy is a tradeoff between consistency, latency, and complexity — Cache-Aside for flexibility, Write-Through for consistency, Write-Behind for write performance, Read-Through for clean app logic, and Refresh-Ahead for zero miss latency — with the right choice always depending on your read/write ratio, consistency requirements, and failure tolerance.
#SystemDesign #Backend #Caching #Redis #WebDevelopment #InterviewPrep #SoftwareEngineering #PerformanceOptimization #EngineeringMindset
SOCIAL SHARE CARD GENERATOR