Patterns

35 items

System Design Pattern

Consistencyeventual-consistencycap-theoremavailabilityasyncconvergenceintermediate

Eventual Consistency Pattern

Trading strong consistency for availability and performance

Used in: DNS, CDNs, Social Media|25 min read

Summary

Eventual Consistency is a consistency model where replicas converge to the same state over time, but may temporarily show different values. Unlike strong consistency which guarantees all nodes see the same data simultaneously, eventual consistency prioritizes availability and partition tolerance (AP in CAP theorem). After writes stop, all replicas eventually converge through asynchronous replication.

Key Takeaways

CAP Theorem Trade-off: Choosing AP over CP

The CAP theorem states distributed systems can only guarantee two of three: Consistency, Availability, Partition tolerance. Since partitions are inevitable, you choose between Consistency (CP) or Availability (AP). Eventual consistency chooses AP.

Convergence Guarantee, Not Time Guarantee

Eventual consistency guarantees that if no new updates are made, all replicas will eventually converge. However, there is no guarantee on how long this takes.

Asynchronous Replication

Writes are acknowledged before propagating to all replicas. This provides low latency but means different replicas temporarily see different values.

Strong consistency requires all nodes to always see the same data. During network partitions (which are inevitable), the system must choose between consistency and availability. Strong consistency means refusing operations during partitions.

Eventual Consistency Replication

Summary

Key Takeaways

CAP Theorem Trade-off: Choosing AP over CP

Convergence Guarantee, Not Time Guarantee

Eventual consistency guarantees that if no new updates are made, all replicas will eventually converge. However, there is no guarantee on how long this takes.

Asynchronous Replication

Writes are acknowledged before propagating to all replicas. This provides low latency but means different replicas temporarily see different values.

Conflict Resolution is Required

Concurrent writes to different replicas create conflicts. The system needs a conflict resolution strategy: Last-Write-Wins, application-level merge, CRDTs, or vector clocks.

Real-World Examples

DNS is eventually consistent—updates take time (TTL) to propagate. CDNs cache content that takes time to invalidate. Social media shows different users different views temporarily.

Monotonic Reads and Session Consistency

Systems often provide weaker guarantees to improve UX: monotonic reads (reads never go backwards), read-your-writes, and session consistency.

Pattern Details

Eventual Consistency Replication

Trade-offs

Aspect	Advantage	Disadvantage

Patterns

Horizontal Scaling Pattern

Retry with Backoff Pattern

Queue-based Load Leveling Pattern

Replication Pattern

Caching Strategies Pattern

Fan-out Pattern

Fan-in Pattern

Persistent Connections Pattern

Load Balancing Pattern

Circuit Breaker Pattern

Bloom Filters Pattern

Time-Series Storage Pattern

Bulkhead Pattern

Batch Processing Pattern

Write-Ahead Log Pattern

API Gateway Pattern

Backend for Frontend Pattern

Sidecar Pattern

Idempotency Pattern

Rate Limiting Pattern

Backpressure Pattern

Pub/Sub Pattern