# Types of Consistency Models Explained: Strong, Weak, and Eventual in Distributed Systems

> Explore strong weak and eventual consistency models in distributed systems Understand how they balance latency availability and data correctness for your applications

- Repository: [Gaurav Kumar/system-design-notes](https://github.com/liquidslr/system-design-notes)
- Tags: deep-dive
- Published: 2026-09-11

---

**Strong, weak, and eventual consistency are the three primary models that define how updates propagate across replicas, each trading off between latency, availability, and data correctness.**

In distributed systems, consistency models govern when modifications to replicated data become visible to clients. The `liquidslr/system-design-notes` repository documents these fundamental patterns in its key-value store architecture section, illustrating how quorum parameters and CAP theorem constraints determine the appropriate model for different use cases.

## Strong Consistency

**Strong consistency** guarantees that any read operation returns the most recent write. According to the source code analysis in `06. Key-Value Store/Readme.md` (lines 96-100), this is achieved by ensuring that the write quorum **W** and read quorum **R** satisfy the condition **W + R > N**, where **N** represents the total number of replicas.

Systems that cannot tolerate stale data rely on this model. The repository specifically references `26. Payment System/README.md` as an example where strong consistency is mandatory for financial transactions, and `24. S3-like Object Storage/README.md` demonstrates its application in object storage systems requiring immediate visibility of updates.

```python
def strong_consistency_example():
    N = 3; W = 2; R = 2               # W+R = 4 > N

    replicas = [Node(i) for i in range(N)]
    write('user:1', {'balance': 100}, W, N, replicas)
    balance = read('user:1', R, N, replicas)
    print('Strong:', balance)

```

This approach aligns with **CP systems** (Consistency + Partition tolerance) under the CAP theorem, as noted in lines 42-46 of the key-value store documentation. During network partitions, these systems sacrifice availability to maintain correctness.

## Weak Consistency

**Weak consistency** offers no guarantee that a read reflects the latest write. Clients may receive outdated values immediately after an update, making this model suitable when low latency outweighs the need for exact freshness.

The repository identifies logging and analytics pipelines as typical use cases for this approach. Unlike strong consistency, weak consistency does not enforce quorum constraints, allowing reads and writes to succeed with minimal replica coordination.

```python
def weak_consistency_example():
    N = 3; W = 1; R = 1               # W+R = 2 ≤ N

    replicas = [Node(i) for i in range(N)]
    write('session:xyz', {'active': True}, W, N, replicas)
    state = read('session:xyz', R, N, replicas)
    print('Weak:', state)

```

## Eventual Consistency

**Eventual consistency** ensures that, given enough time without further writes, all replicas converge to the same state. This model powers high-availability systems like social media feeds and DNS caches, where temporary divergence is acceptable.

As implemented in the repository's examples, this pattern uses minimal quorum requirements (typically W=1, R=1) to maximize write throughput and availability. The `06. Key-Value Store/Readme.md` file classifies this under **AP systems** (Availability + Partition tolerance), which prioritize responsiveness over immediate consistency during network partitions.

```python
def eventual_consistency_example():
    N = 3; W = 1; R = 1               # Writes go to a single node

    replicas = [Node(i) for i in range(N)]
    write('feed:post42', {'likes': 5}, W, N, replicas)
    # Reads may hit a replica that hasn't received the latest write yet

    likes = read('feed:post42', R, N, replicas)
    print('Eventual (may be stale):', likes)

```

## Quorum Mechanics and Implementation

The distinction between these models hinges on **quorum parameters**. The repository provides Python helper functions illustrating how distributed key-value stores implement these guarantees:

```python
def write(key, value, W, N, replicas):
    ack = 0
    for r in replicas:
        if r.store(key, value):   # Assume store returns True on success

            ack += 1
        if ack >= W:
            break
    return ack >= W

def read(key, R, N, replicas):
    responses = []
    for r in replicas:
        val = r.fetch(key)         # Assume fetch returns (value, version)

        if val is not None:
            responses.append(val)
        if len(responses) >= R:
            break
    # Return the most recent version from the collected responses

    return max(responses, key=lambda x: x[1])[0] if responses else None

```

*Note:* The `Node` class represents a replica implementing `store()` and `fetch()` methods. In production systems like Cassandra or DynamoDB, client libraries handle this quorum logic internally.

## Additional Considerations in System Design

The consistency model selection extends beyond the key-value store implementation. The repository's `01. Scaling/Readme.md` discusses consistency in the context of cache-database synchronization, while payment systems and object storage implementations demonstrate how business requirements dictate the strictness of consistency guarantees.

## Summary

- **Strong consistency** requires **W + R > N** quorum math, ensuring fresh reads at the cost of availability during partitions (CP systems).
- **Weak consistency** allows stale reads with minimal latency, ideal for logging and non-critical analytics.
- **Eventual consistency** guarantees convergence over time, supporting high-availability architectures like social feeds and DNS (AP systems).
- These models are defined in `06. Key-Value Store/Readme.md` and applied across various system designs in the repository.

## Frequently Asked Questions

### What is the relationship between consistency models and the CAP theorem?

According to the `liquidslr/system-design-notes` repository, consistency models map directly to CAP theorem trade-offs. **CP systems** enforce strong consistency during network partitions but sacrifice availability, while **AP systems** maintain availability by accepting eventual consistency. This classification appears in `06. Key-Value Store/Readme.md` (lines 42-46).

### How do quorum reads and writes determine consistency levels?

Quorum parameters define the minimum number of replicas that must acknowledge an operation. When **W + R > N**, the read and write quorums overlap, guaranteeing strong consistency. When **W + R ≤ N**, the system permits weak or eventual consistency, allowing greater parallelism but risking stale reads.

### When should I choose strong consistency over eventual consistency?

Select strong consistency for systems where data correctness is critical and stale reads are unacceptable, such as financial transactions in payment systems or inventory management. Choose eventual consistency when availability and partition tolerance are paramount, such as in social media feeds, DNS resolution, or global content delivery networks.

### Can a single distributed system support multiple consistency models?

Yes. Many modern distributed databases allow per-operation or per-table consistency configuration. The repository's examples demonstrate that by adjusting **W** and **R** parameters dynamically, the same underlying replica set can provide strong consistency for critical operations while offering eventual consistency for high-throughput workloads.