Store copies of hot data in a fast layer to reduce latency and database load.

Data Flow (cache-aside, the most common)

READ  : client -> app -> cache? yes: return
                              no:  app -> DB, populate cache, return
WRITE : client -> app -> DB  -> (invalidate cache or write-through)

Four write strategies

• Read-through: cache itself loads from DB on miss.
• Write-through: every write hits cache and DB synchronously.
• Write-behind: writes hit cache, then async to DB (loses durability; risky).
• Cache-aside (“lazy”): app owns the cache; on miss, app loads DB and sets cache. App also invalidates on write.

Pitfalls

• Stale cache when writes don’t invalidate.
• Thundering herd when 1000 requests miss at once and stampede the DB. Use single-flight locks (asyncio.Lock, Redis SETNX) on the miss path.
• Hot key contention when 90% of reads target the same key — shard the key (e.g. key:<i> for i in 0..3).

Code (Python cache-aside)

async def get_user(uid):
    cached = await redis.get(f"user:{uid}")
    if cached: return json.loads(cached)
    user = await db.fetch("SELECT * FROM users WHERE id=$1", uid)
    await redis.set(f"user:{uid}", json.dumps(user), ex=300)
    return user

Analogy

Post-it notes on your desk vs the filing cabinet: a single source of truth (cabinet) with a fast cache (post-it).

Interview tip: State the write strategy by name (read-through, write-behind, etc.) and the invalidation policy.