Cache Consistency Patterns

This simulation demonstrates the fundamental trade-offs between performance, consistency, and complexity in different caching patterns, directly relating to concepts from our Caches Lie: Consistency Isn't Free post.

The Three Fundamental Patterns

🔄 Cache-Aside (Lazy Loading)

Application manages the cache manually

# Read pattern
def get_user(user_id):
    user = cache.get(f"user:{user_id}")
    if user is None:  # Cache miss
        user = database.get_user(user_id)
        cache.set(f"user:{user_id}", user, ttl=300)
    return user

# Write pattern
def update_user(user_id, data):
    database.update_user(user_id, data)
    cache.delete(f"user:{user_id}")  # Invalidate

✅ Pros: Simple, fail-safe, cache failure doesn't block writes ❌ Cons: Cache warming required, potential stale reads

⚡ Write-Through (Synchronous)

Cache coordinates database updates

def update_user(user_id, data):
    # Both operations must succeed
    cache.set(f"user:{user_id}", data)
    database.update_user(user_id, data)
    return "success"

✅ Pros: Strong consistency, automatic cache population ❌ Cons: Higher write latency, cache failure affects writes

🚀 Write-Behind (Asynchronous)

Cache accepts writes, database updated later

def update_user(user_id, data):
    # Write to cache immediately
    cache.set(f"user:{user_id}", data)
    # Queue for database write
    write_queue.add({
        'operation': 'update_user',
        'user_id': user_id,
        'data': data
    })
    return "success"  # Fast response

✅ Pros: Ultra-fast writes, high throughput, write batching ❌ Cons: Eventual consistency, data loss risk on cache failure

Key Insights to Explore

1. The Consistency-Performance Trade-off

Watch how consistency levels change as you switch between patterns:

• Write-through: 99% consistency, higher latency
• Cache-aside: 95% consistency, moderate latency
• Write-behind: 60-90% consistency, lowest latency

2. Load Distribution Effects

Observe how database load varies with each pattern:

• High read/write ratio: Write-behind shines
• High write load: Write-through struggles
• Cache failures: Cache-aside most resilient

3. Batching Benefits (Write-Behind)

Increase batch size and watch:

• System load decreases (fewer database operations)
• Consistency drops (longer delays)
• Data loss risk increases (more data in flight)

Real-World Scenarios

E-commerce Product Catalog

// High read, low write - Write-through ideal
const pattern = 'write-through';
const config = {
  writeLoad: 10,    // Product updates rare
  readLoad: 2000,   // Heavy browsing
  hitRate: 90       // Popular products cached
};

Social Media Feed

// High write, high read - Write-behind optimal
const pattern = 'write-behind';
const config = {
  writeLoad: 500,   // Constant posts/likes
  readLoad: 3000,   // Timeline reads
  batchSize: 50     // Batch social signals
};

User Authentication

// Critical consistency - Cache-aside safest
const pattern = 'cache-aside';
const config = {
  writeLoad: 50,    // Login state changes
  readLoad: 800,    // Session validation
  consistency: 100  // Security critical
};

Performance Implications

Write Latency Breakdown

• Cache-aside: ~50ms (DB only)
• Write-through: ~51ms (cache + DB sequential)
• Write-behind: ~1ms (cache only)

Read Latency with 80% Hit Rate

• Cache hit: ~1ms (all patterns)
• Cache miss: ~50ms (DB fetch)
• Average: ~11ms (weighted average)

Throughput Limitations

# Maximum theoretical throughput
max_writes_per_sec = 1000 / write_latency_ms
max_reads_per_sec = 1000 / read_latency_ms

# Actual throughput limited by slowest operation
actual_throughput = min(requested_load, theoretical_max)

Failure Scenarios

Cache Failure Impact

• Cache-aside: Reads slower, writes unaffected
• Write-through: All writes fail (unless fallback implemented)
• Write-behind: Potential data loss for pending writes

Database Failure Impact

• Cache-aside: Reads from cache continue, writes fail
• Write-through: All operations fail
• Write-behind: Writes continue to cache, queue builds up

Advanced Optimizations

Hybrid Patterns

Many production systems combine patterns:

class HybridCache:
    def update_critical_data(self, key, data):
        # Critical data: write-through
        self.cache.set(key, data)
        self.database.update(key, data)

    def update_metrics(self, key, data):
        # Metrics: write-behind
        self.cache.set(key, data)
        self.metrics_queue.add(key, data)

    def get_data(self, key):
        # Always cache-aside for reads
        return self.cache.get(key) or self.fetch_and_cache(key)

Consistency Levels

• Strong consistency: Write-through only
• Eventual consistency: Write-behind with monitoring
• Session consistency: Cache-aside with proper invalidation

Interactive Experiments

Experiment 1: Pattern Comparison

1. Set moderate load (100 writes/s, 500 reads/s)
2. Switch between all three patterns
3. Compare latency, consistency, and system load

Experiment 2: Load Testing

1. Choose write-behind pattern
2. Gradually increase write load from 10 to 1000
3. Observe how batching helps system load

Experiment 3: Failure Resilience

1. Set cache failure rate to 5%
2. Compare how each pattern handles failures
3. Notice write-through's vulnerability

Experiment 4: Consistency Requirements

1. Set high write load (500 writes/s)
2. Adjust batch size in write-behind
3. Find the sweet spot between performance and consistency

Production Considerations

Choosing the Right Pattern

Use Cache-Aside when:

• System reliability is paramount
• Cache failures must not affect writes
• Complex invalidation logic needed

Use Write-Through when:

• Strong consistency required
• Read-heavy workload with occasional writes
• Simple consistency model preferred

Use Write-Behind when:

• Write performance is critical
• Eventual consistency acceptable
• High write throughput needed

Monitoring Metrics

• Hit rate: Cache effectiveness
• Write latency: User experience impact
• Queue depth: Write-behind health
• Consistency lag: Data freshness
• Error rates: System reliability

Remember: The best caching pattern depends on your specific consistency requirements, performance needs, and failure tolerance. There's no one-size-fits-all solution.