Cache Strategies: Cache-Aside vs Write-Through vs Write-Behind

TL;DR. Cache-aside is the right default for read-heavy workloads: the application owns the miss-and-populate logic, the database stays authoritative, and a cache outage degrades performance without losing data.¹ Switch to write-through when read-your-writes is a product requirement (account balances, feature flags). Use write-behind only for reconstructable, high-throughput writes (counters, telemetry) where you accept a data-loss window equal to the flush interval.² Most production systems combine all three, classified per field.

Learning Objectives

• Compare cache-aside, write-through, and write-behind across consistency, latency, durability, and operational complexity.
• Identify the workload characteristics (read:write ratio, staleness tolerance, durability needs) that determine which strategy wins.
• Justify a hybrid approach that layers write-through onto cache-aside for critical fields.
• Evaluate real-world systems (Facebook Memcache, TAO, Netflix EVCache) and explain why each chose its strategy.

The Core Trade-off

A cache strategy is a contract about which failure mode you pay for. The three dimensions that cannot all be optimized simultaneously are:

1. Consistency between cache and database costs extra writes on the write path.
2. Low miss latency costs memory and admission-policy complexity.
3. Durability costs write throughput because every write must reach persistent storage before acknowledgment.¹²

Cache-aside optimizes the read path and accepts eventual consistency on writes. Write-through optimizes read-your-writes and accepts extra write latency. Write-behind optimizes write throughput and accepts a data-loss window on cache failure.²

The non-linearity is what catches teams off guard: a hit-rate drop from 99% to 98% doubles database load.³ That single percentage point is the difference between a healthy system and a cascading failure.

sequenceDiagram
    participant App
    participant Cache
    participant DB
    Note over App,DB: Cache-aside (read path)
    App->>Cache: GET key
    alt hit
        Cache-->>App: value
    else miss
        Cache-->>App: nil
        App->>DB: SELECT
        DB-->>App: row
        App->>Cache: SETEX key TTL value
    end
    Note over App,DB: Write-through (write path)
    App->>Cache: PUT key=v
    Cache->>DB: INSERT/UPDATE
    DB-->>Cache: ack
    Cache-->>App: ok
    Note over App,DB: Write-behind (write path)
    App->>Cache: PUT key=v
    Cache-->>App: ok (NOT yet in DB)
    Cache->>DB: async batch flush

Side-by-Side Comparison

The table misleads on one dimension: write-through’s “full durability” assumes the DB write succeeds before the cache is updated. If you update the cache first and the DB write fails, you have a stale cache entry with no TTL to save you. Order matters: DB first, cache second.³

Write-behind’s “sub-ms read latency” is only true if the reader goes through the cache. Any read that bypasses to the database sees stale data until the next flush.²

When to Pick Cache-Aside

• Read:write ratio exceeds 10:1. Facebook Memcache serves billions of reads per second with ~99% hit rate against MySQL backends that handle ~100K queries/sec per server.³ The 10x gap between cache and DB throughput is the economic argument.
• Cache is a performance layer, not a correctness layer. If Redis goes down, the system degrades to database-only operation. Painful, but not data-losing.
• Multiple services read the same keys. Each service manages its own get-or-populate logic. No central cache library required.
• You can tolerate bounded staleness. TTL caps the blast radius of invalidation bugs to seconds or minutes, not forever.¹
• Write patterns are diverse. Many code paths update the same entity. Using delete (not set) on write avoids the stale-set race under concurrent updates.³

When to Pick Write-Through/Write-Behind

Write-through when:

• Read-your-writes is a hard product requirement. Account balances, RBAC permissions, feature-flag state. A user who changes their password must not see the old one on the next page load.
• The write rate is modest. DynamoDB DAX uses write-through for PutItem and UpdateItem; the extra latency is acceptable because DynamoDB writes are already single-digit ms.²
• You want zero drift between cache and DB. Facebook TAO uses write-through from leader caches to MySQL, eliminating the invalidation-race bugs that plagued raw Memcache.⁵

Write-behind when:

• Write throughput is the bottleneck and the data is reconstructable. View counters, analytics events, personalization signals. Losing one second of counter increments is not a correctness bug.
• You need 10-100x write throughput improvement. Redis AOF with appendfsync everysec is write-behind at the durability layer: up to one second of writes can be lost on crash.⁴
• Batching and coalescing reduce backend load. Multiple updates to the same key collapse into one DB write, cutting write amplification.²

The Hybrid Path

Most production systems default to cache-aside for reads and layer write-through onto the small set of fields where read-your-writes is a product requirement. Write-behind appears narrowly for high-throughput, low-value writes. Mixing strategies per field is the norm, not the exception.¹⁶

flowchart TD
    A[Incoming write] --> B{Field classification}
    B -->|Critical: balance, permissions| C[Write-through]
    B -->|Standard: profile, preferences| D[Cache-aside with delete]
    B -->|High-volume: counters, telemetry| E[Write-behind]
    C --> F[DB + cache updated synchronously]
    D --> G[DB updated, cache key deleted]
    E --> H[Cache updated, async flush to DB]

Facebook’s architecture demonstrates this: Memcache (cache-aside) handles the general read workload, TAO (write-through) handles the social graph where invalidation races are unacceptable, and internal counters use write-behind for throughput.⁵³

Real-World Examples

Facebook Memcache (2013). Billions of requests/sec, trillions of items, ~99% hit rate.⁷ Cache-aside with delete on write (not set) because delete is commutative under concurrent updates. Leases serialize thundering-herd refills: on miss, Memcached hands a one-time token to the first requester; others retry. McSqueal tails the MySQL binlog to broadcast cross-region invalidations.³

Facebook TAO (2013). Over 1 billion reads/sec, millions of writes/sec across a large fleet of geographically distributed server clusters.⁵ Write-through from leader caches to MySQL. Two-tier topology (followers serve reads, leaders own writes) reduces MySQL fan-in. The team switched from cache-aside specifically because the stale-set races in Memcache were too costly for graph data.⁵

Netflix EVCache (2024). As of 2024, 400 million ops/sec, 14.3 PB across 22,000 instances in four AWS regions.⁸ Cache-aside with client-initiated cross-region replication via Kafka (metadata-only payloads, not values). SSD-backed tier (extstore) trades higher latency for significantly lower cost per GB versus RAM-only.⁸

Common Mistakes

Decision Checklist

• What is the read:write ratio? If >10:1, cache-aside is almost always correct.
• Does the user see stale data after their own write? If yes, write-through for that field.
• If the cache crashes with N unflushed writes, what is the business impact?
• Is your invalidation strategy correct across all cache replicas and all regions?
• Do you have a TTL on every cached key, even as a backstop?
• Are you monitoring cache hit rate as a first-class SLI?
• Is the data reconstructable from an upstream source? If not, write-behind is off the table.

Key Takeaways

• Cache-aside is the default. It works for >90% of read-heavy workloads and degrades gracefully on cache failure.
• Write-through buys read-your-writes at the cost of write latency. Use it narrowly for fields where staleness is a correctness bug.
• Write-behind is the strategy that will silently eat your data. Restrict it to reconstructable, high-volume writes.
• Always use delete (not set) on the write path to avoid stale-set races under concurrency.³
• TTL is both a freshness knob and a bug blast-radius cap. Set one on every key.

Further Reading

• Scaling Memcache at Facebook (NSDI 2013) - the canonical cache-aside paper; leases, McSqueal, and the “why delete not set” argument originate here.
• TAO: Facebook’s Distributed Data Store for the Social Graph - graph-aware write-through cache that replaced raw Memcache for social data.
• Netflix EVCache Global Replication (InfoQ, 2024) - modern production numbers for a Memcached-based global cache at 400M ops/sec.
• DynamoDB DAX: Read-Through/Write-Through Cache - clearest prose definition of read-through vs write-through vs side-cache.
• Cache made consistent (Engineering at Meta, 2022) - 10-year retrospective on closing invalidation races in Memcache/TAO.
• Optimal Probabilistic Cache Stampede Prevention (Vattani et al.) - the XFetch algorithm for smoothing TTL-boundary stampedes.

Flashcards

graph TD
    A[Need a cache strategy?] -->|Read:write > 10:1| B[Cache-aside]
    A -->|Read-your-writes required| C[Write-through]
    A -->|Write throughput bottleneck| D{Data reconstructable?}
    D -->|Yes| E[Write-behind]
    D -->|No| C
    B --> F{Staleness acceptable?}
    F -->|Yes, bounded by TTL| G[Done: cache-aside + TTL + delete on write]
    F -->|No, for specific fields| H[Hybrid: cache-aside + write-through for critical fields]

References