Caching Patterns: Read-Through, Write-Through, and Busting

Quickstart

Want fast wins without turning your system into a cache-themed escape room? Use these steps in order. They prioritize correctness and operational sanity over “maximum hit rate.”

Overview

“Caching Patterns: Read-Through, Write-Through, and Busting” is really about one question: where do you want the complexity to live? You can hide complexity in the application, push it into a caching layer, or avoid it by accepting bounded staleness.

Core concepts

Before you pick a caching pattern, align on a mental model. A cache is a derived copy of data that is safe to discard. The source of truth (database, service, API) is still responsible for correctness.

The caching triangle: latency, correctness, simplicity

Key definitions you’ll use everywhere

Cache busting: TTL, invalidation, and versioned keys

Cache stampede (thundering herd)

A stampede happens when many requests simultaneously miss the cache (often right after an expiry) and all hit the database. The fix is not “increase TTL” (though it helps); it’s to add a coordination mechanism: a lock, single-flight, or stale-while-revalidate behavior for safe data.

Step-by-step

Below is a practical implementation path used in many production systems: start with read-through for safe wins, introduce write-through (or invalidate-on-write) only where it matters, then add a busting strategy that matches your data model.

Step 0 — Decide what you’re caching

Step 1 — Implement read-through (cache-aside) with sane TTL

Read-through is the best default because you can ship it incrementally: add cache reads, measure hit rate, and you haven’t changed write semantics. The two things you must handle from day one are (1) TTL jitter and (2) stampede protection.

import json
import random
import time
from typing import Any, Dict, Optional

import redis

r = redis.Redis(host="localhost", port=6379, decode_responses=True)

def db_get_user(user_id: str) -> Dict[str, Any]:
    # Replace with your DB call
    return {"id": user_id, "name": "Ada", "plan": "pro", "updated_at": int(time.time())}

def get_user_read_through(user_id: str) -> Dict[str, Any]:
    """
    Read-through (cache-aside):
      1) Try cache
      2) On miss, load from DB
      3) Populate cache with TTL (+ jitter)
    Includes lightweight stampede protection via a short lock.
    """
    key = f"app:prod:user:{user_id}"
    lock_key = f"{key}:lock"
    ttl_seconds = 300  # 5 minutes, example
    ttl_jitter = random.randint(0, 30)  # spread expirations to reduce herd

    cached: Optional[str] = r.get(key)
    if cached:
        return json.loads(cached)

    # Try to become the "refresher"
    got_lock = r.set(lock_key, "1", nx=True, ex=10)
    if not got_lock:
        # Someone else is refreshing; brief wait then try cache again
        time.sleep(0.05)
        cached2 = r.get(key)
        if cached2:
            return json.loads(cached2)
        # Fallback: don't block forever; go to DB as last resort

    data = db_get_user(user_id)
    r.set(key, json.dumps(data), ex=ttl_seconds + ttl_jitter)
    r.delete(lock_key)
    return data

Step 2 — Add write-through (or write + invalidate) for read-after-write paths

If your product expects a user to see their changes immediately (settings, checkout, account state), TTL-only caching can feel “buggy.” You have two practical options:

// Write-through example (Node/Express-style pseudocode).
// Goal: after updating the DB, keep the cache aligned for read-after-write flows.

async function updateUser(req, res) {
  const userId = req.params.userId;
  const patch = req.body;

  const cacheKey = `app:prod:user:${userId}`;

  // 1) Update the source of truth first.
  // In real code: wrap this in a transaction if multiple tables are involved.
  const updated = await db.users.update(userId, patch);

  // 2) Best-effort cache update.
  // If this fails, correctness is still preserved (DB is truth); cache will heal on next read.
  try {
    const ttlSeconds = 300;
    await redis.set(cacheKey, JSON.stringify(updated), { EX: ttlSeconds });
  } catch (err) {
    // Log and move on: don't fail the write just because the cache hiccupped.
    logger.warn({ err, userId }, "cache_update_failed");
  }

  return res.json(updated);
}

Step 3 — Cache busting that actually stays correct

Cache busting is the part most teams underestimate. A single entity is easy to invalidate; derived views are not. If you cache: lists (team members), aggregates (counts), or composed pages (dashboard), you need a strategy that doesn’t require remembering twenty keys on every write.

# Versioned key "busting" using Redis.
# Pattern:
#   - Keep a version counter per group (e.g., user dashboard)
#   - Read uses the current version in the key
#   - Busting increments the version (old keys become obsolete)

# Read path (conceptual):
#   v=$(redis-cli GET app:prod:user:42:dash:ver || echo 1)
#   key="app:prod:user:42:dash:v${v}"
#   redis-cli GET "$key"

# Bust path (on writes that affect the dashboard):
redis-cli INCR app:prod:user:42:dash:ver

# Optional hygiene: ensure the version key itself expires if users go inactive
# (choose a long TTL that matches your product usage patterns)
redis-cli EXPIRE app:prod:user:42:dash:ver 2592000  # 30 days

Common mistakes

Most caching incidents look like “stale data” or “database overload,” but the root cause is usually a predictable design miss. Here are the classics—plus fixes you can apply without a rewrite.

FAQ

When should I use read-through caching vs write-through caching?

Use read-through as the default when your service is read-heavy and you can tolerate bounded staleness. Reach for write-through (or write + invalidate) when users expect read-after-write correctness and the cached data maps cleanly to a single key (like “user by ID”).

What’s the safest way to avoid stale data disasters?

Be explicit about freshness and align it with your busting strategy. If staleness is acceptable, use TTL and keep it documented. If not, invalidate on writes or use versioned keys for derived views. Then add stampede protection so expiry doesn’t become an outage.

How do I choose the right TTL?

Choose TTL from business freshness requirements, not from performance intuition. Start with “how old can this data be without causing user harm?” Then add jitter (a small random offset) to spread expirations. If a strict freshness requirement exists, TTL alone is not enough—pair it with invalidation or versioned keys.

Is write + invalidate better than write-through?

Often, yes. Write + invalidate is simpler when cached values are derived (lists, aggregates) or when computing the correct cache value during a write is tricky. You update the DB, delete affected keys, and let read-through repopulate. Write-through is great when you’re caching an entity record that you already have after the write.

How do I prevent cache stampedes when many keys expire?

Use coordination: a short lock, single-flight, and TTL jitter. For safe data, consider stale-while-revalidate (serve slightly stale and refresh in the background). Also watch for deploys that cold-start many instances—pre-warm only the truly critical keys.

Should I cache “not found” responses?

Yes, carefully. Negative caching can drastically reduce DB load for missing IDs or repeated lookups, but keep TTL short and be sure it won’t hide newly created records longer than acceptable.

What’s a good key naming convention?

Use a predictable prefix + environment + entity + identifier: app:prod:user:42, app:prod:user:42:dash:v7. This makes it easier to monitor, reason about invalidations, and avoid collisions across services.

Cheatsheet

Scan this when you’re implementing caching patterns under time pressure.

Wrap-up

Caching is one of the highest-leverage performance tools in software architecture—when you treat it as an optimization, not as a second source of truth. If you take only a few lessons from “Caching Patterns: Read-Through, Write-Through, and Busting,” take these:

• Start with read-through for safe, incremental wins.
• Use write-through or invalidate-on-write only where read-after-write matters.
• Pick a busting strategy (TTL, targeted invalidation, versioned keys) and make it observable.
• Prevent stampedes with jitter and coordination so expiry doesn’t become an outage.

Related posts

• Caching Strategies: CDN, Server, Browser (And When Each Wins)
• Clean Architecture Explained With a Tiny Example App
• Domain-Driven Design Lite: The Useful 20%
• Event-Driven Architecture: When Events Actually Help
• Design for Observability: Logs, Metrics, Traces as Requirements
• Dependency Hell Prevention: Modular Boundaries and APIs