A practical walkthrough of the cache-aside pattern — why it exists, how to implement it, and what breaks if you skip it.
When I built Flacron Gamezone, one of the first questions I had to answer wasn't about the UI or the API design. It was simpler and more uncomfortable than that: what happens when fifty users refresh the live scores page at the same time?
The honest answer, without caching, is that all fifty of them hit the database. And then the next fifty do the same. And the one after that. For a football platform where the data changes every few minutes but gets read thousands of times between those changes, that's a lot of identical queries doing identical work for no reason.
This is the problem Redis solves. More specifically, it's the problem the cache-aside pattern solves. Here's how I implemented it, what it looks like in production, and why the details matter.
Why Not Just Cache Everything?
Before getting into implementation, it's worth being honest about the tradeoff you're making when you add a cache.
Every cached value is a bet: you're betting that serving slightly stale data is better than the cost of hitting the database every time. For most data on most applications, that bet is obviously correct. But there are places where it isn't — user account data, payment state, anything where correctness matters more than speed.
On Flacron Gamezone, the split was clear:
- Live match data — read constantly, changes infrequently, perfect for caching
- User subscription status — hits Stripe and the database, should never be stale
- Authentication tokens — never cached, always verified fresh
Getting this split right before you write a single line of caching code matters more than any implementation detail.
The Cache-Aside Pattern
Cache-aside (also called lazy loading) is the most common caching strategy, and for good reason — it's simple, it's predictable, and it fails gracefully.
The logic on every read request is:
- Check the cache first
- If the value is there (cache hit), return it
- If it's not (cache miss), fetch from the database, store it in the cache, then return it
That's it. The cache only gets populated with data that's actually been requested. You're not pre-loading anything speculatively.
Here's what this looks like in code, in the context of the match service:
// services/matchService.ts
import { redis } from "../lib/redis";
import { matchRepository } from "../repositories/matchRepository";
const CACHE_TTL_SECONDS = 60; // 1 minute for live match data
export async function getLiveMatches(): Promise<Match[]> {
const cacheKey = "matches:live";
// Step 1: Check the cache
const cached = await redis.get(cacheKey);
if (cached) {
return JSON.parse(cached);
}
// Step 2: Cache miss — fetch from database
const matches = await matchRepository.findLive();
// Step 3: Store in cache with TTL, then return
await redis.set(cacheKey, JSON.stringify(matches), "EX", CACHE_TTL_SECONDS);
return matches;
}
Clean, readable, and the logic is entirely self-contained in the service layer. The controller doesn't know caching exists. The repository doesn't know either. That separation matters when you need to change the caching strategy later.
Setting Up the Redis Client
I'm using Upstash for Redis in production — it's serverless, has a generous free tier, and works well with Vercel deployments. Locally, I run Redis via Docker.
// lib/redis.ts
import { Redis } from "@upstash/redis";
export const redis = new Redis({
url: process.env.UPSTASH_REDIS_REST_URL!,
token: process.env.UPSTASH_REDIS_REST_TOKEN!,
});
One thing worth noting: Upstash uses an HTTP-based client (@upstash/redis), not the traditional ioredis TCP connection. For serverless environments, this is actually the correct choice — TCP connections don't survive the stateless nature of serverless functions well. If you're running a persistent Express server (not serverless), ioredis is the standard option.
Cache Invalidation: The Hard Part
There's a famous saying in computer science: "There are only two hard things: cache invalidation and naming things." It's a cliché because it's true.
Cache-aside with a TTL handles the simple case automatically — the cache entry expires after 60 seconds, and the next request repopulates it. For live match scores, this is acceptable. A one-minute lag in a score update isn't a product failure.
But for data that changes on user action — like when an admin updates match details — waiting for TTL expiry isn't good enough. You need active invalidation.
// services/matchService.ts
export async function updateMatch(id: string, data: Partial<Match>): Promise<Match> {
const updated = await matchRepository.update(id, data);
// Invalidate related cache keys immediately after a write
await redis.del("matches:live");
await redis.del(`match:${id}`);
return updated;
}
The rule I follow: every write operation that could affect a cached read should also delete those cache keys. The next read will repopulate the cache with fresh data automatically. You're not managing the cache value directly — you're just telling it to forget what it knows.
Handling Cache Failures Gracefully
Here's something tutorials almost never cover: what happens when Redis goes down?
If your application throws an unhandled error every time the cache is unavailable, you've traded a performance problem for an availability problem. The whole point of a cache is to be an optimization, not a dependency.
The fix is straightforward — wrap cache operations in try/catch and fall through to the database on failure:
export async function getLiveMatches(): Promise<Match[]> {
const cacheKey = "matches:live";
try {
const cached = await redis.get(cacheKey);
if (cached) {
return JSON.parse(cached);
}
} catch (err) {
// Redis is unavailable — log it, but don't crash
console.error("Cache read failed, falling back to DB:", err);
}
const matches = await matchRepository.findLive();
try {
await redis.set(cacheKey, JSON.stringify(matches), "EX", CACHE_TTL_SECONDS);
} catch (err) {
// Cache write failed — still return the data
console.error("Cache write failed:", err);
}
return matches;
}
Your app is slower when Redis is down. It is not broken. That's the correct behavior.
What the Numbers Actually Look Like
Before caching, every request to the live matches endpoint was a database query. On a day with multiple live matches and active users, that's potentially hundreds of queries per minute for data that changes once every sixty seconds.
After caching, the database sees one query per minute for live match data regardless of traffic. Everything else is served from memory in under a millisecond. That's not a marginal improvement — it's a fundamentally different load profile.
The TTL is the lever you control. Lower it and your data is fresher but your cache hit rate drops. Raise it and your hit rate improves but stale data becomes more of a risk. For Flacron Gamezone, 60 seconds was the right balance. For a financial dashboard, you'd probably drop it to 5 or 10. For a product catalog that rarely changes, you might go hours.
What I'd Do Differently
One thing I got wrong early on was using overly broad cache keys. I had a single matches:all key that cached the entire match list. The moment I added pagination, that key became useless — the cached value was always the wrong page.
The right approach is to build cache keys that reflect exactly what was queried:
const cacheKey = `matches:status:${status}:page:${page}:limit:${limit}`;
More keys means more cache entries to manage and invalidate, but it also means your cache is actually useful across different query shapes. The tradeoff is worth it.
Summary
The cache-aside pattern is three steps: check the cache, miss to the database, write back. The important decisions are around which data to cache, what TTL makes sense for your use case, how to invalidate on writes, and how to handle cache failures without taking down your application.
None of this requires a complex setup. A single Redis client, one utility function, and consistent discipline about where caching logic lives in your service layer is enough to meaningfully change how your backend performs under load.
Flacron Gamezone is live at flacrongamezone.com. If you're building a backend and want a developer who thinks about these problems before they become production incidents, reach me at syedahmedali.com.
Top comments (0)