Write-Back (Write-Behind) Caching

The fundamental promise of write-back caching is performance: specifically, dramatically faster write operations. But how much faster? Under what conditions? And where exactly does the speedup come from?

This page quantifies and explains the performance benefits of write-back caching. We'll examine latency improvements, throughput multiplication, the magic of write coalescing, and the scenarios where write-back caching delivers transformational performance gains versus modest improvements.

Understanding these benefits precisely enables you to make informed decisions about when write-back caching is worth its complexity—and when simpler patterns suffice.

The most immediate and visible benefit of write-back caching is write latency reduction. Let's break down exactly where this improvement comes from.

Anatomy of a synchronous database write:

Client Request
    │
    ├── Application processing: ~1ms
    │
    ├── Network to database: ~2ms (in same datacenter)
    │
    ├── Database processing:
    │   ├── Parse query: ~0.1ms
    │   ├── Acquire locks: ~0.5ms
    │   ├── Write to WAL: ~2ms (fsync to disk)
    │   ├── Update B-tree/index: ~1ms
    │   ├── Release locks: ~0.1ms
    │   └── Total: ~4ms
    │
    ├── Network from database: ~2ms
    │
    └── Response to client
    
Total: ~9-10ms typical (can be 20-50ms under load)

Anatomy of a write-back cache write:

Client Request
    │
    ├── Application processing: ~1ms
    │
    ├── Network to cache: ~0.5ms (same datacenter, optimized protocol)
    │
    ├── Cache processing:
    │   ├── Hash lookup: ~0.01ms
    │   ├── Memory write: ~0.001ms
    │   ├── Mark dirty: ~0.001ms
    │   └── Total: ~0.02ms
    │
    ├── Network from cache: ~0.5ms
    │
    └── Response to client
    
Total: ~2ms typical

The latency math:

Improvement factor: 5x typical, up to 25x under load

The savings come from:

1. No disk I/O — Cache writes go to memory, not disk. SSDs are fast, but RAM is 100-1000x faster.
2. No fsync — Database durability requires flushing to persistent storage. Cache skips this entirely.
3. No lock contention — Databases acquire row/page locks. Caches use simpler, faster concurrency.
4. Simpler protocol — Cache protocols (Redis, Memcached) are optimized for speed. Database protocols have more overhead.
5. Proximity — Caches are often deployed closer to applications, reducing network latency.

While latency measures individual operation speed, throughput measures how many operations the system can handle per second. Write-back caching dramatically increases write throughput.

The throughput equation:

Throughput is fundamentally limited by:

Max Throughput = Resources / Time_per_operation

For a database:
    Resources: Connection pool (e.g., 100 connections)
    Time_per_operation: 10ms average
    Max Throughput: 100 / 0.010 = 10,000 writes/second

For a cache:
    Resources: Connection pool (e.g., 100 connections)
    Time_per_operation: 1ms average  
    Max Throughput: 100 / 0.001 = 100,000 writes/second

10x throughput improvement just from faster operations.

But the benefit is actually larger because caches are designed for higher connection counts:

Real-world throughput example:

Workload: Social media like counter
    - 10,000 likes per second at peak
    - Each like = 1 database write

With direct database writes:
    - Database capacity: 5,000 writes/sec
    - At 10,000 likes/sec: System overloaded, latency spikes, potential failure
    - Solution: Add database replicas (expensive, complex)

With write-back caching:
    - Cache capacity: 200,000 writes/sec (single node)
    - At 10,000 likes/sec: 5% of capacity, smooth operation
    - Flush to database: Batched, coalesced, easily within DB capacity
    - Solution: Works with existing infrastructure

The throughput multiplier effect:

Write-back caching improves throughput in three ways:

1. Faster individual operations — More ops per second per connection
2. Higher connection limits — More concurrent operations possible
3. Write coalescing — Fewer total operations needed (covered next section)

Combined, these can provide 50-100x effective throughput improvement for suitable workloads.

Write coalescing is where write-back caching delivers its most dramatic performance gains. When the same key is written multiple times before a flush, only the final value needs to be persisted. For hot keys with frequent updates, this reduces database writes by orders of magnitude.

The coalescing principle:

Without coalescing (every write to database):
    T0: Write key=counter, value=1    → DB write
    T1: Write key=counter, value=2    → DB write
    T2: Write key=counter, value=3    → DB write
    ...
    T999: Write key=counter, value=1000 → DB write
    
    Total: 1000 database writes

With write-back coalescing (flush every 1000 writes):
    T0-T999: All writes update cache, value evolves 1→1000
    T1000: Flush - Write key=counter, value=1000 → DB write
    
    Total: 1 database write
    
    Reduction: 1000x

When coalescing has maximum impact:

The "hot key problem" becomes your advantage:

In traditional databases, hot keys are a problem—they create contention, lock conflicts, and bottlenecks. With write-back caching, hot keys are actually ideal: the hotter the key, the more coalescing benefit.

Example: Video view counter (viral video)

    View rate: 50,000 views/second
    Flush interval: 1 second
    
    Database writes without caching: 50,000/second
    Database writes with write-back: 1/second
    
    Coalescing factor: 50,000x

This is not a typo. For extremely hot keys, coalescing provides five orders of magnitude reduction in database load.

Beyond latency and throughput improvements, write-back caching fundamentally changes database load characteristics. This has profound implications for database sizing, cost, and reliability.

How database load changes:

Before Write-Back Caching:

    Application ──[100,000 writes/sec]──▶ Database
    
    - Database must handle entire write load
    - Spikes directly impact database
    - Need database capacity for peak load
    - Write contention under high load

After Write-Back Caching:

    Application ──[100,000 writes/sec]──▶ Cache ──[10,000 writes/sec]──▶ Database
    
    - Database handles 10x fewer writes (from coalescing)
    - Batched writes are more efficient
    - Spikes absorbed by cache
    - Steady, predictable database load

The spike absorption effect:

One of the most valuable but often overlooked benefits is spike absorption:

Traffic Pattern (writes/second):

    Without caching (database sees):
    
    10K ─────╮
             │         ╭── Peak: 50K writes/sec
    30K ─────┤    ╭────╯   (database must handle)
             │   ╱
    50K ─────┼──╯     <-- Traffic spike
             │   ╲
    30K ─────┤    ╰────╮
             │         ╰── Return to baseline
    10K ─────╯

    With write-back caching (database sees):
    
    10K ─────────────────── Steady ~15K writes/sec
                            (coalesced, smoothed)
                            Database easy to provision

The cache acts as a shock absorber, smoothing traffic spikes that would otherwise stress or overwhelm the database. This allows you to size the database for average load plus a reasonable buffer, rather than for peak load.

Performance improvements translate directly to user experience. Let's examine how write-back caching affects what users perceive.

Response time perception:

Human perception of response times follows well-studied patterns:

Moving a write operation from 50ms (database) to 2ms (cache) keeps users in the "instant" zone, maintaining flow and satisfaction.

Real-world UX scenarios:

Scenario 1: Social Media Posting

User taps "Post" button

Without write-back:
    Spinner shows for 50-100ms (database write)
    User notices slight delay
    Under load: 200ms+ delay, feels sluggish
    
With write-back:
    Post appears instantly (~2ms)
    User never sees spinner
    Under load: Still instant, cache absorbs spike

Scenario 2: E-commerce Add to Cart

User clicks "Add to Cart"

Without write-back:
    50ms delay before confirmation
    Double-click risk if user doesn't see response
    Under load: noticeable delays, poor experience
    
With write-back:
    Cart updates immediately
    Confirmation instant
    Cache handles Black Friday traffic gracefully

Scenario 3: Real-time Game Actions

Player fires weapon / moves character

Without write-back:
    50ms+ state persistence delay
    In 60fps game: 3+ frames of lag
    Competitive disadvantage, player frustration
    
With write-back:
    State update in ~2ms
    Less than 1 frame of processing time
    Smooth, competitive gameplay

Write-back caching provides varying degrees of benefit depending on workload characteristics. Understanding where benefits are maximized helps you prioritize where to apply this pattern.

Benefit magnitude by workload type:

The workload analysis framework:

When evaluating whether write-back caching will help, analyze:

1. Write Volume Analysis:
   - Total writes per second (current and projected)
   - Percentage of writes vs reads
   - Growth rate of write traffic

2. Key Distribution Analysis:
   - Are writes spread evenly or concentrated on hot keys?
   - Top 10% of keys: what % of writes?
   - Hottest key: how many writes/second?

3. Tolerance Analysis:
   - Can the application tolerate N seconds of data loss?
   - Do downstream systems need immediate visibility?
   - Are there regulatory constraints on persistence?

4. Infrastructure Analysis:
   - Current database utilization
   - Cost of database scaling vs caching
   - Operational capability for caching layer

If answers favor write-back (high volume, concentrated keys, tolerant of delayed persistence), the pattern will deliver significant benefits.

Quantifying performance benefits requires systematic measurement. Here's how to benchmark write-back caching for your specific workload.

Metrics to measure:

Benchmarking methodology:

Phase 1: Baseline (Without Write-Back)
    1. Configure to write directly to database
    2. Generate representative write traffic
    3. Measure latency distribution (p50, p95, p99, p999)
    4. Measure maximum sustainable throughput
    5. Record database CPU, IOPS, connection utilization

Phase 2: With Write-Back
    1. Configure write-back caching with production flush settings
    2. Generate identical write traffic
    3. Measure latency distribution at application layer
    4. Measure maximum sustainable throughput
    5. Record cache utilization, flush rates, DB metrics
    6. Track coalescing ratio and dirty entry counts

Phase 3: Analysis
    1. Calculate latency improvement (baseline / with-cache)
    2. Calculate throughput improvement 
    3. Calculate DB write reduction (coalescing effect)
    4. Estimate cost savings from smaller DB / lower IOPS
    5. Document operational complexity increase

Load testing considerations:

• Test at various load levels (50%, 100%, 150%, 200% of expected peak)
• Test with realistic key distributions (Zipfian for social workloads)
• Test failure scenarios (cache failover, DB slowdown)
• Run long enough for flush cycles to stabilize (at least 10x flush interval)
• Measure both cache and database during tests

Write-back caching delivers substantial performance benefits for suitable workloads. Let's consolidate what we've learned:

The performance equation:

Write-back caching trades durability risk (bounded by flush interval) for dramatic performance improvements. The trade-off is worthwhile when:

1. The performance gain is substantial (10x+ throughput or coalescing)
2. The durability risk is acceptable (bounded data loss tolerance)
3. The added complexity can be managed (operational capability exists)

What's next:

Now that we understand the benefits, the final page examines the other side: durability concerns. We'll explore what can go wrong, how much data you can lose, and how to minimize risk while preserving performance gains.