Write path: Write to both cache and database atomically (or in sequence). The cache always reflects the latest write.

When to Use Write-Through

• Write-heavy with frequent re-reads — data is written once and read many times before the next write
• Consistency is important — reads always see the latest write
• Data must not be stale — user sessions, inventory counts, balances

Trade-offs and Failure Modes

Write latency doubles: Every write waits for both the database and Redis to acknowledge. If Redis is slow, all writes are slow.

Cache pollution: You write to the cache whether or not the data is ever read again. Short-lived objects (created once, never read) consume cache memory unnecessarily. Mitigate with appropriate TTLs.

Partial failure: If the database write succeeds but the Redis write fails (network blip), the cache is stale. If the database write fails but Redis succeeds, the cache is incorrect. Neither is catastrophic for cache-aside (you can retry), but for write-through, you should treat the database as the source of truth and consider the cache write a best-effort update.

---

Pattern 3: Write-Behind (Write-Back)

Write-behind acknowledges the write after updating only the cache. The cache write to the database happens asynchronously — in a background job or queue.

How It Works

Writes go to Redis immediately. A background worker (queue consumer, cron job, or Redis keyspace notification listener) propagates changes to the database asynchronously.

When to Use Write-Behind

• Write-heavy, latency-sensitive workloads — real-time gaming scores, analytics counters, activity feeds
• Writes that can tolerate temporary inconsistency — if Redis crashes before the background flush, the write is lost
• Aggregation before persistence — batching 1,000 counter increments into a single database UPDATE

Trade-offs and Failure Modes

Data loss on Redis crash: If Redis loses data (no persistence configured, or between AOF flushes) before the background job writes to the database, the writes are permanently lost. This is the most dangerous failure mode in caching. Only use write-behind when data loss is acceptable.

Ordering: The background job must process writes in order. If write B overwrites write A, but the background job processes B before A, the database ends up with stale data. Use a queue (Redis List or Stream) to ensure ordering.

Complexity: The background flush mechanism is additional infrastructure to build, test, and operate.

---

Pattern 4: Read-Through

Read-through is cache-aside with the cache itself responsible for loading from the database on a miss — the application talks only to the cache abstraction, which handles database fallback internally.

How It Works

The API is identical to cache-aside from the application's perspective:

The difference is implementation: the cache layer is a wrapper that handles the miss logic itself. Libraries like cache-manager (Node.js) implement this pattern.

cache.wrap checks the cache, calls the factory function on a miss, stores the result, and returns it — all transparently.

When to Use Read-Through

• When you want to centralize cache miss logic in a single place
• When multiple parts of the application cache the same keys — consistency of TTL and serialization
• As a facade over cache-aside for cleaner application code

---

Choosing the Right Pattern

Decision framework:

• Is Redis purely a read cache (source of truth is the DB)? → Cache-Aside
• Do reads immediately after writes need fresh data? → Write-Through
• Is write latency the primary concern and data loss is acceptable? → Write-Behind
• Do you want clean application code with centralized miss handling? → Read-Through

Most production systems use Cache-Aside as the default and add Write-Through for specific high-consistency keys (sessions, inventory, balances).

---

Cache Invalidation Strategies

"There are only two hard things in computer science: cache invalidation and naming things." — Phil Karlton

The harder problem is not which pattern to use — it is knowing when to invalidate.

Invalidation on Write (Proactive)

Delete the cache key immediately after the corresponding database row is written:

Risk: The DEL and the UPDATE are not atomic. A crash between the two leaves the cache stale. Mitigate by doing DEL before the UPDATE (stale but empty is safer than stale with wrong data) or by using a transaction with a message queue.

TTL-Based Expiry (Passive)

Let cache keys expire naturally. Stale data is served until TTL expires. Simple, but bounded staleness.

Event-Driven Invalidation

Use a message broker (Redis Streams, BullMQ, Kafka) to publish invalidation events. Cache consumers subscribe and delete their local copies:

This pattern is essential for multi-region deployments where each region has its own Redis instance and invalidations must propagate globally.

---

Cache Warm-Up

After a Redis restart or a new cache cluster deployment, the cache is empty. Every request is a miss until the cache fills — this is a "cold start." For high-traffic systems, a cold cache means a temporary database overload.

Warm-up strategies:

1. Eager warm-up — on startup, fetch the most-accessed keys from the database and pre-populate the cache
2. Shadow traffic — replay recent production traffic against the new cache instance before routing live traffic
3. Gradual rollout — route 5% of traffic to the new Redis instance, let it warm, then gradually increase

---

Summary

• Cache-Aside — read from cache, fall back to DB on miss, write to DB and invalidate cache on writes. Default pattern. Simple, resilient, eventual consistency.
• Write-Through — write to both cache and DB synchronously. Strong read consistency after writes. Higher write latency. Good for sessions and balances.
• Write-Behind — write to cache immediately, flush to DB asynchronously. Lowest write latency. Risk of data loss on Redis crash.
• Read-Through — cache handles its own miss logic. Clean application code. Same consistency as cache-aside.
• Cache stampede — expired popular key → N concurrent DB queries. Mitigate with mutex locks or probabilistic early expiry.
• Cache invalidation — proactive DEL after DB writes, or TTL-based expiry. Neither is perfectly safe under concurrent modification.
• Cache warm-up — pre-populate after cold start to protect the database from the thundering herd of cache misses.

---

This completes the Foundation tier. You have covered the full Redis data model, all major data structures and their encodings, TTL and eviction mechanics, HyperLogLog/Bitmaps/Geo, pipelining, Pub/Sub, Streams, memory internals, transactions, and caching patterns.

The Practitioner tier begins with the infrastructure questions: how does Redis persist data to survive a restart?

Next: P-1 — RDB Snapshots: Point-in-Time Persistence — how Redis writes its entire in-memory dataset to disk, the fork-and-copy-on-write mechanism, snapshot configuration, and when RDB is the right (and wrong) persistence strategy.

---