Database Query Caching Strategies Cheat Sheet
Query caching patterns covering cache-aside, write-through, Redis-backed result caching, invalidation, and stampede prevention.
2 PagesIntermediateJun 8, 2026
Cache-Aside (Lazy Loading)
The most common pattern: check cache first, fall back to DB, populate cache on miss.
typescript
async function getUser(id: string): Promise<User> { const cacheKey = `user:${id}`; const cached = await redis.get(cacheKey); if (cached) return JSON.parse(cached); const user = await db.query('SELECT * FROM users WHERE id = $1', [id]); await redis.set(cacheKey, JSON.stringify(user), 'EX', 300); // TTL 5 min return user;}async function updateUser(id: string, data: Partial<User>) { await db.query('UPDATE users SET name = $1 WHERE id = $2', [data.name, id]); await redis.del(`user:${id}`); // invalidate on write}
Cache Stampede Prevention
Prevent thousands of concurrent requests from all missing the cache and hammering the DB at once.
typescript
async function getUserWithLock(id: string): Promise<User> { const cacheKey = `user:${id}`; const cached = await redis.get(cacheKey); if (cached) return JSON.parse(cached); const lockKey = `lock:${cacheKey}`; const gotLock = await redis.set(lockKey, '1', 'NX', 'EX', 5); if (!gotLock) { // Another request is already refilling the cache; wait briefly and retry await sleep(50); return getUserWithLock(id); } try { const user = await db.query('SELECT * FROM users WHERE id = $1', [id]); await redis.set(cacheKey, JSON.stringify(user), 'EX', 300); return user; } finally { await redis.del(lockKey); }}
Write-Through & Tag-Based Invalidation
Keep cache consistent on writes, and invalidate related keys via tags.
typescript
// Write-through: update cache and DB together, in the same requestasync function writeThroughUpdate(id: string, data: Partial<User>) { const updated = await db.query( 'UPDATE users SET name = $1 WHERE id = $2 RETURNING *', [data.name, id]); await redis.set(`user:${id}`, JSON.stringify(updated), 'EX', 300); return updated;}// Tag-based invalidation using a set of keys per tagasync function cacheWithTag(key: string, tag: string, value: string, ttl: number) { await redis.set(key, value, 'EX', ttl); await redis.sadd(`tag:${tag}`, key);}async function invalidateTag(tag: string) { const keys = await redis.smembers(`tag:${tag}`); if (keys.length) await redis.del(...keys); await redis.del(`tag:${tag}`);}
Strategy Comparison
Which caching pattern fits which access profile.
- Cache-aside- app manages cache explicitly on read miss; simplest, most common, cache can drift briefly stale
- Write-through- cache updated synchronously with every write; always consistent, adds write latency
- Write-behind (write-back)- writes go to cache first, flushed to DB asynchronously; fast writes, risk of data loss on crash
- Read-through- cache library itself fetches from DB on miss, transparent to the app
- TTL-based expiry- simplest invalidation strategy; balance staleness tolerance against cache hit rate
- Cache stampede / dogpile- many requests missing simultaneously on a hot key's expiry; mitigate with locks or early refresh
Negative Caching (Cache Misses)
Cache the absence of a record too, with a short TTL, to stop repeated DB hits from clients probing for nonexistent IDs.
typescript
const NOT_FOUND = '__NF__';async function getUserSafe(id: string): Promise<User | null> { const cacheKey = `user:${id}`; const cached = await redis.get(cacheKey); if (cached === NOT_FOUND) return null; if (cached) return JSON.parse(cached); const user = await db.query('SELECT * FROM users WHERE id = $1', [id]); if (!user) { // Short TTL: don't let a since-created record stay hidden long await redis.set(cacheKey, NOT_FOUND, 'EX', 30); return null; } await redis.set(cacheKey, JSON.stringify(user), 'EX', 300); return user;}
Probabilistic Early Expiration (XFetch)
Refresh hot keys slightly before real expiry, probabilistically, so no single request pays the full recompute cost at TTL boundary and stampedes never form.
typescript
async function getWithXFetch<T>( key: string, ttl: number, beta: number, compute: () => Promise<T>): Promise<T> { const raw = await redis.get(key); if (raw) { const { value, storedAt, delta } = JSON.parse(raw); const elapsed = (Date.now() - storedAt) / 1000; // Probability of early refresh grows as we approach ttl const shouldRefresh = elapsed - delta * beta * Math.log(Math.random()) >= ttl; if (!shouldRefresh) return value; } const start = Date.now(); const value = await compute(); const delta = (Date.now() - start) / 1000; // recompute cost, used to weight future refreshes await redis.set(key, JSON.stringify({ value, storedAt: Date.now(), delta }), 'EX', ttl * 2); return value;}
Two-Tier Cache: In-Process LRU + Redis
Absorb the hottest keys in an in-process LRU to skip network round-trips entirely, falling back to Redis for the broader working set.
typescript
import { LRUCache } from 'lru-cache';const local = new LRUCache<string, string>({ max: 5000, ttl: 5_000 }); // short local TTLasync function getCached(key: string, ttl: number, load: () => Promise<string>): Promise<string> { const l1 = local.get(key); if (l1) return l1; const l2 = await redis.get(key); if (l2) { local.set(key, l2); return l2; } const value = await load(); await redis.set(key, value, 'EX', ttl); local.set(key, value); return value;}// Invalidate both tiers on write; local caches on other instances// still expire quickly (5s) so staleness window is boundedasync function invalidate(key: string) { local.delete(key); await redis.del(key);}
Materialized View as a Query-Layer Cache
Push expensive aggregation caching into Postgres itself with a concurrently-refreshable materialized view, avoiding an external cache for read-heavy reporting queries.
sql
CREATE MATERIALIZED VIEW daily_revenue ASSELECT date_trunc('day', created_at) AS day, SUM(amount) AS totalFROM ordersGROUP BY 1;CREATE UNIQUE INDEX ON daily_revenue (day); -- required for CONCURRENTLY-- Refresh without blocking readers of the current dataREFRESH MATERIALIZED VIEW CONCURRENTLY daily_revenue;-- Typically scheduled via pg_cron or an application job every N minutesSELECT cron.schedule('refresh-daily-revenue', '*/10 * * * *', 'REFRESH MATERIALIZED VIEW CONCURRENTLY daily_revenue');
Cache Consistency & Failure Modes
Deeper failure scenarios beyond the basic strategy comparison — what breaks in production and why.
- Thundering herd on deploya fresh deploy/restart with a cold cache causes a full-traffic stampede against the DB; pre-warm hot keys before flipping traffic
- Race between invalidate and populatea stale read racing a concurrent write can repopulate the cache with old data right after invalidation; delete-then-write-with-version or delayed double-delete mitigates it
- Partial failure (write succeeds, invalidate fails)network blip after DB commit but before cache DEL leaves permanently stale data; use a message queue or CDC stream to drive invalidation reliably
- Cache incoherence across regionsmulti-region Redis replicas can lag; reads in the follower region may serve stale data even with correct TTLs — accept it or route consistency-critical reads to primary
- Hot key overloada single celebrity key (e.g. viral post) can saturate one Redis shard; mitigate with local L1 caching or key sharding (key:0..key:9 fan-out)
- Serialization costlarge JSON blobs cost more CPU to (de)serialize than the DB round-trip saved; cache smaller derived views, not entire rows, for big objects
Pro Tip
Add small random jitter to TTLs (e.g. `300 + random(0,30)` seconds) instead of a fixed value — when you cache many keys at once with identical TTLs, they all expire in the same instant and recreate the stampede problem you were trying to avoid.
Was this cheat sheet helpful?
Explore Topics
#DatabaseQueryCachingStrategies#DatabaseQueryCachingStrategiesCheatSheet#Database#Intermediate#Cache#Aside#Lazy#Loading#Databases#CheatSheet#SkillVeris
