Data Written to Cache and Database Together

In the first page, we established that write-through caching writes to both cache and database synchronously. But what does "together" really mean in the context of distributed systems? Can we truly write to two different systems simultaneously? What happens when one succeeds and the other fails?

These questions cut to the heart of distributed systems theory. The two-generals problem teaches us that achieving perfect coordination between two separate systems is theoretically impossible. Yet write-through caching manages to provide strong consistency guarantees in practice. Understanding how it achieves this—and its limitations—is essential for building reliable systems.

This page examines the coordination mechanisms that make write-through caching work, the consistency models it provides, and the subtle edge cases that can still occur.

When we say data is written to cache and database "together," we need to be precise about what this means—and what it doesn't mean.

What "Together" DOES Mean:

1. Sequential execution in a single operation — Both writes occur as part of one logical operation from the application's perspective
2. Causal ordering — The database write completes before the cache write begins
3. Cross-system consistency — At rest, cache and database contain the same value for any given key
4. Single point of failure awareness — The application knows immediately if either write fails

What "Together" DOES NOT Mean:

1. Atomic transaction — There is no distributed transaction coordinator ensuring both succeed or both fail
2. Simultaneous execution — The writes happen sequentially, not in parallel
3. Two-phase commit — No prepare/commit protocol spans both systems
4. Rollback capability — If the cache write fails after DB success, there's no automatic rollback

The Consistency Window:

Between the database write completing and the cache write completing, there's a brief window where the two systems are inconsistent:

Time  │  Database State  │  Cache State  │  System Consistency
──────┼──────────────────┼───────────────┼────────────────────
 T0   │  value = A       │  value = A    │  ✓ Consistent
 T1   │  value = B       │  value = A    │  ✗ Inconsistent (window opens)
 T2   │  value = B       │  value = B    │  ✓ Consistent (window closes)

This window typically lasts milliseconds (the time to update the cache), but it exists. During this window:

• A read from the cache returns stale data (value A)
• A read from the database returns fresh data (value B)

For most applications, this window is negligible. But for systems requiring strict linearizability, this is a crucial consideration.

The coordination protocol in write-through caching follows a specific sequence designed to maximize consistency while minimizing complexity. Let's examine each phase in detail.

Phase 1: Write Initiation

The application initiates a write operation. This phase establishes the write context:

┌─────────────────────────────────────────────────────────────┐
│                    WRITE INITIATION                          │
├─────────────────────────────────────────────────────────────┤
│ 1. Application prepares write payload                        │
│ 2. Optionally acquire distributed lock (if needed)           │
│ 3. Generate idempotency key (for retry safety)               │
│ 4. Open database connection (or acquire from pool)           │
│ 5. Begin implicit or explicit transaction                    │
└─────────────────────────────────────────────────────────────┘

Phase 2: Database Write

The database write is the authoritative operation. Key considerations:

• Transaction isolation — Choose appropriate isolation level (READ COMMITTED is typically sufficient)
• Durability guarantee — Wait for fsync/commit confirmation before proceeding
• Error classification — Distinguish retriable errors (deadlock, timeout) from permanent failures (constraint violation)

Phase 3: Cache Synchronization

After database success, update the cache:

• Serialization — Convert the database result to cache-friendly format
• TTL assignment — Set appropriate expiration time
• Error handling — Decide policy for cache failures (see code above)

Phase 4: Finalization

Complete the write operation:

• Release locks — If distributed lock was acquired
• Record metrics — Track latencies and success rates
• Return result — Confirm success to caller

Write-through caching provides different consistency guarantees depending on implementation choices. Understanding these models helps you choose the right configuration for your use case.

Read-After-Write Consistency (Default):

This is what write-through provides naturally. If Client A writes a value and then reads it, they're guaranteed to see their write:

Client A: WRITE(key, 'value1') → SUCCESS
Client A: READ(key) → 'value1' ✓ (guaranteed)

Client B: READ(key) → 'value1' or 'old_value' (depends on timing)

This works because:

1. Write updates cache synchronously before returning
2. Subsequent reads from the same client hit the updated cache
3. No cross-client coordination is needed

Strengthening Consistency with Versions:

For stronger guarantees, implement version-aware caching:

The most challenging aspect of dual-write coordination is handling partial failures—when one system succeeds and the other fails. Let's examine each scenario and the strategies to address them.

Strategy 1: Accept Temporary Inconsistency

The pragmatic approach for most systems: accept that a cache write failure after DB success results in temporary staleness.

Database Write Success
        ↓
Cache Write Attempt
        ↓
    ┌───┴───┐
    │ FAIL  │
    └───┬───┘
        ↓
Log Error + Return Success
        ↓
Next Read → Cache Miss → Load from DB → Cache Populated
        ↓
Consistency Restored

When to use: Most applications where occasional stale reads (for seconds) are acceptable.

Strategy 2: Background Retry with Dead Letter Queue

For systems needing faster convergence, implement async retry:

Strategy 3: Compensating Transaction (Strict Mode)

For systems requiring strict consistency, rollback the database write on cache failure:

Database Write Success
        ↓
Cache Write Attempt
        ↓
    ┌───┴───┐
    │ FAIL  │
    └───┬───┘
        ↓
Begin Compensating Transaction
        ↓
Rollback Database Write
        ↓
Return Failure to Client

Caution: This approach is complex and introduces its own failure modes. What if the rollback fails? You need careful saga-style orchestration. Generally not recommended unless absolutely necessary.

When multiple clients write to the same key simultaneously, the "together" guarantee becomes more complex. We need to ensure that both the database and cache end up with the same final value.

The Race Condition Problem:

Consider two concurrent writes:

Time   │ Client A                    │ Client B
───────┼─────────────────────────────┼─────────────────────────
 T0    │ DB.write(key, 'A')          │                          
 T1    │                              │ DB.write(key, 'B')        
 T2    │ DB returns success          │                          
 T3    │                              │ DB returns success        
 T4    │ Cache.set(key, 'A')         │                          
 T5    │                              │ Cache.set(key, 'B')       

Database final value: 'B' (last write wins) Cache final value: 'B' (last write wins) Result: Consistent ✓

This case works correctly. But consider a different timing:

Time   │ Client A                    │ Client B
───────┼─────────────────────────────┼─────────────────────────
 T0    │ DB.write(key, 'A')          │                          
 T1    │                              │ DB.write(key, 'B')        
 T2    │ DB returns success          │                          
 T3    │                              │ DB returns success        
 T4    │                              │ Cache.set(key, 'B')       
 T5    │ Cache.set(key, 'A')         │                          

Database final value: 'B' (Client B wrote last) Cache final value: 'A' (Client A's cache write happened last) Result: Inconsistent ✗

The cache and database disagree because the cache writes happened in reverse order of the database writes.

Solution 1: Optimistic Versioning

Use versions to detect and resolve conflicts:

Solution 2: Distributed Locking

Serialize writes to prevent concurrent access:

How you structure data in the cache affects the "together" guarantee. Different patterns have different trade-offs for consistency and performance.

Recommended Pattern: Whole Object with Versioning

For write-through caching, storing whole objects with version metadata provides the best balance of consistency and simplicity:

// Cache entry structure
{
  "key": "user:12345",
  "value": {
    "id": 12345,
    "name": "Alice",
    "email": "alice@example.com",
    "preferences": { "theme": "dark", "notifications": true }
  },
  "meta": {
    "version": 42,
    "updatedAt": 1704672000000,
    "ttl": 3600
  }
}

This structure ensures:

• Atomic cache updates (the whole object is replaced)
• Version tracking for conflict detection
• Timestamp for debugging and monitoring
• Clear TTL management

We've explored what it means to write data to cache and database "together" in write-through caching. Let's consolidate the key insights:

What's Next:

With a deep understanding of how cache and database are coordinated, we're ready to explore the consistency benefits of write-through caching. The next page examines why write-through provides stronger guarantees than other caching patterns and when these benefits matter most.