Consistency models (strong, eventual) in HLD - System Design Guide

Problem Statement

When multiple copies of data exist across servers, they can become out of sync. This causes users to see different versions of the same data, leading to confusion, errors, or lost updates. Without a clear consistency approach, systems struggle to guarantee reliable and predictable data behavior.

Solution

Consistency models define rules for how and when updates to data become visible across all copies. Strong consistency ensures all users see the latest data immediately by synchronizing updates before confirming success. Eventual consistency allows temporary differences but guarantees all copies will converge to the same state over time, improving availability and performance.

Architecture

Client A

→Server 1

↓

Client B

This diagram shows clients interacting with multiple servers holding copies of data. Strong consistency synchronizes all servers before confirming updates, while eventual consistency allows asynchronous updates that converge over time.

Trade-offs

✓ Pros

→

Strong consistency guarantees users always see the latest data, preventing stale reads.

→

Eventual consistency improves system availability and reduces latency by allowing asynchronous updates.

→

Eventual consistency scales better in distributed systems with high write loads.

✗ Cons

→

Strong consistency can increase response times due to synchronization delays and reduce availability during network partitions.

→

Eventual consistency can cause temporary data conflicts and stale reads, requiring conflict resolution mechanisms.

→

Strong consistency is harder to implement in geo-distributed systems due to network latency.

Use strong consistency when correctness and up-to-date data are critical, such as financial transactions or inventory management. Use eventual consistency for high-scale, distributed systems where availability and low latency are more important than immediate consistency.

Avoid strong consistency in systems with high network latency or frequent partitions where availability is critical. Avoid eventual consistency when stale or conflicting data can cause serious errors or user dissatisfaction.

Real World Examples

Amazon DynamoDB

Uses eventual consistency by default to provide low-latency reads across distributed data centers, allowing high availability even during network partitions.

Google Spanner

Provides strong consistency globally by synchronizing data with precise time coordination, ensuring all clients see the latest data immediately.

Facebook

Uses eventual consistency for social feed updates to improve performance and availability, accepting temporary stale views for users.

Alternatives

Causal consistency

Ensures operations that are causally related are seen in order, but unrelated operations may be seen out of order.

Use when: Choose when you need a balance between strong and eventual consistency, preserving cause-effect relationships without full synchronization.

Read-your-writes consistency

Guarantees a user always sees their own updates immediately, but not necessarily others' updates.

Use when: Choose when user experience requires immediate visibility of their own changes but global synchronization is not needed.

Summary

Consistency models define how data updates propagate and become visible across distributed systems.

Strong consistency ensures all users see the latest data immediately but can reduce availability and increase latency.

Eventual consistency allows temporary differences but improves availability and scales better in distributed environments.