Write-Through

How Write-Through Works

Write-Through ensures data is written to both cache and database synchronously before returning to the client.

Flow Diagram

Write-Through Flow:

App → Write to Cache → Write to DB (synchronous) → Acknowledge to App

1. Data written to cache first
2. Data written to database
3. Both writes must succeed
4. Client receives acknowledgment after both complete

Implementation

class WriteThroughCache:
    def __init__(self, cache_client, db_client):
        self.cache = cache_client
        self.db = db_client
    
    def set(self, key, value, ttl=3600):
        """Write-through: write to cache AND database"""
        # Write to cache first
        self.cache.set(key, value, ttl)
        
        # Write to database
        self.db.upsert(key, value)
        
        return True
    
    def delete(self, key):
        """Delete from both cache and database"""
        self.cache.delete(key)
        self.db.delete(key)
        return True

# Usage
cache = WriteThroughCache(redis_client, db_client)
cache.set('user:123', user_data)  # Writes to both Redis and DB

Characteristics

1. Synchronous writes to both cache and DB
2. Strong consistency - cache and DB always in sync
3. Higher write latency due to dual writes
4. Cache is always warm for recently written data

Write-Through Consistency

Strong Consistency Guarantee

Consistency Model:

After write completes:
- Cache: Contains new value ✓
- Database: Contains new value ✓
- Both are identical ✓

No stale data possible!

Comparison with Other Patterns

Pattern	Consistency	Write Latency	Cache State
Cache-Aside	Eventual	Low	May be stale
Write-Through	Strong	High	Always fresh
Write-Behind	Eventual	Low	May be stale

Handling Failures

def write_through_with_failure_handling(key, value):
    """Write-through with proper failure handling"""
    try:
        # Start transaction
        with db.transaction():
            # Write to database first (source of truth)
            db.upsert(key, value)
            
            # Then update cache
            cache.set(key, value, ttl=3600)
        
        return True
    except Exception as e:
        # Rollback database if cache write fails
        db.rollback()
        raise e

Why Write to DB First?

• Database is the source of truth
• If cache write fails, DB still has the data
• Cache will be populated on next read (Cache-Aside style)
• Maintains data durability

Performance Impact of Write-Through

Write Latency Analysis

Write Latency Breakdown:

Without Cache:
App → DB Write (50ms) → Response = 50ms total

With Write-Through:
App → Cache Write (1ms) → DB Write (50ms) → Response = 51ms total

Overhead: ~2% increase in write latency

Throughput Considerations

Metric	Without Cache	With Write-Through
Write Latency	50ms	51-55ms
Write Throughput	1,000 WPS	800-900 WPS
Read Latency	100ms	1-5ms
Read Throughput	10,000 RPS	100,000+ RPS

Optimizing Write-Through

class OptimizedWriteThrough:
    def __init__(self, cache, db, batch_size=100):
        self.cache = cache
        self.db = db
        self.batch_size = batch_size
        self.write_buffer = []
    
    def set(self, key, value):
        """Buffer writes for batch processing"""
        # Immediate cache write for reads
        self.cache.set(key, value, ttl=3600)
        
        # Buffer DB writes for batching
        self.write_buffer.append((key, value))
        
        if len(self.write_buffer) >= self.batch_size:
            self.flush_buffer()
    
    def flush_buffer(self):
        """Batch write to database"""
        if self.write_buffer:
            self.db.batch_upsert(self.write_buffer)
            self.write_buffer = []

When to Use Write-Through

Good for:

• Read-heavy workloads with occasional writes
• When strong consistency is required
• Data that's expensive to compute
• Leaderboards, counters, session data

Not ideal for:

• Write-heavy workloads (use Write-Behind)
• When write latency is critical
• Bulk data imports
• Analytics workloads