Consistency models (strong, eventual) in HLD - Architecture Diagram

System Overview - Consistency models (strong, eventual)

This system demonstrates two common data consistency models used in distributed systems: strong consistency and eventual consistency. It shows how data updates propagate and how clients read data under each model, highlighting trade-offs between immediacy and availability.

Architecture Diagram

          +------------+          +----------------+          +------------+
          |   Client   |          |   Client       |          |   Client   |
          | (Read/Write|          | (Read Only)    |          | (Read Only)|
          +-----+------+          +-------+--------+          +-----+------+
                |                         |                         |
                |                         |                         |
                v                         v                         v
        +-------+---------+       +-------+---------+       +-------+---------+
        | Load Balancer   |       | Load Balancer   |       | Load Balancer   |
        +-------+---------+       +-------+---------+       +-------+---------+
                |                         |                         |
                |                         |                         |
      +---------+---------+     +---------+---------+     +---------+---------+
      | API Gateway       |     | API Gateway       |     | API Gateway       |
      +---------+---------+     +---------+---------+     +---------+---------+
                |                         |                         |
                |                         |                         |
      +---------+---------+     +---------+---------+     +---------+---------+
      | Strong Consistency |     | Eventual Consistency|    | Eventual Consistency|
      | Service           |     | Service             |    | Service             |
      +---------+---------+     +---------+---------+     +---------+---------+
                |                         |                         |
                |                         |                         |
      +---------+---------+     +---------+---------+     +---------+---------+
      | Primary Database  |     | Primary Database  |     | Replica Database  |
      +---------+---------+     +---------+---------+     +---------+---------+
                |                         |                         |
                |                         |                         |
      +---------+---------+     +---------+---------+     +---------+---------+
      | Replication Queue |<----| Replication Queue |<----| Replication Queue |
      +-------------------+     +-------------------+     +-------------------+

Components

Client

user

Users who send read and write requests to the system

Load Balancer

load_balancer

Distributes incoming client requests evenly to API Gateways

API Gateway

api_gateway

Handles client requests, routes them to appropriate consistency service

Strong Consistency Service

service

Processes requests ensuring all reads see the latest writes immediately

Eventual Consistency Service

service

Processes requests allowing some delay before all replicas are updated

Primary Database

database

Stores the authoritative data and handles writes

Replica Database

database

Stores copies of data for read scalability and eventual consistency

Replication Queue

queue

Queues data changes to replicate asynchronously to replicas

Request Flow - 11 Hops

Client → Load Balancer

Load Balancer → API Gateway

API Gateway → Strong Consistency Service

Strong Consistency Service → Primary Database

Primary Database → Replication Queue

Replication Queue → Replica Database

API Gateway → Eventual Consistency Service

Eventual Consistency Service → Primary Database

Eventual Consistency Service → Replica Database

API Gateway → Load Balancer

Load Balancer → Client

Failure Scenario

Component Fails:Primary Database

Impact:Writes fail causing data updates to stop; strong consistency reads fail; eventual consistency reads may still serve stale data from replicas

Mitigation:Use database replication and failover to standby primary; cache reads from replicas; queue writes until primary recovers

Architecture Quiz - 3 Questions

Which component ensures that all clients see the latest data immediately after a write?

A Strong Consistency Service

B Replication Queue

C Load Balancer

D Replica Database

Design Principle

This architecture shows the trade-off between strong and eventual consistency. Strong consistency guarantees immediate data correctness but with higher latency and less availability. Eventual consistency improves availability and read scalability by allowing replicas to lag behind, accepting temporary stale reads.

Practice

1. Which statement best describes strong consistency in distributed systems?

easy

A. All users see the same data immediately after an update.

B. Data updates are delayed and may differ temporarily between users.

C. Data is never synchronized between nodes.

D. Users see different versions of data permanently.

Solution

1. Step 1: Understand strong consistency definition

   Strong consistency means every read returns the most recent write, so all users see the same data instantly.

2. Step 2: Compare options with definition

   All users see the same data immediately after an update. matches this definition exactly, while others describe delayed or inconsistent views.

3. Final Answer:

   All users see the same data immediately after an update. -> Option A

4. Quick Check:

   Strong consistency = immediate data sync [OK]

Hint: Strong consistency means instant data visibility everywhere [OK]

Common Mistakes:

• Confusing strong consistency with eventual consistency
• Thinking data can be permanently inconsistent
• Assuming delays are allowed in strong consistency

2. Which of the following is a correct characteristic of eventual consistency?

easy

A. No synchronization happens between nodes.

B. All nodes update simultaneously with no delay.

C. Data is always consistent after every write operation.

D. Data updates propagate over time and become consistent eventually.

Solution

1. Step 1: Recall eventual consistency meaning

   Eventual consistency means updates may take time to reach all nodes, but eventually all nodes will have the same data.

2. Step 2: Match options to definition

   Data updates propagate over time and become consistent eventually. correctly states that data updates propagate over time and become consistent eventually.

3. Final Answer:

   Data updates propagate over time and become consistent eventually. -> Option D

4. Quick Check:

   Eventual consistency = delayed but eventual sync [OK]

Hint: Eventual consistency means data sync happens over time [OK]

Common Mistakes:

• Assuming immediate synchronization in eventual consistency
• Confusing no synchronization with eventual consistency
• Thinking eventual consistency means permanent inconsistency

3. Consider a distributed database using eventual consistency. If a user updates a record on one node, what is the expected behavior immediately after the update?

medium

A. Other nodes may temporarily show the old record until synchronization completes.

B. All other nodes instantly reflect the updated record.

C. The update is rejected until all nodes confirm availability.

D. The record is deleted from all nodes except the updated one.

Solution

1. Step 1: Analyze eventual consistency update behavior

   In eventual consistency, updates propagate asynchronously, so other nodes may temporarily have stale data.

2. Step 2: Evaluate options against this behavior

   Other nodes may temporarily show the old record until synchronization completes. correctly states that other nodes may show old data until synchronization finishes.

3. Final Answer:

   Other nodes may temporarily show the old record until synchronization completes. -> Option A

4. Quick Check:

   Eventual consistency = temporary stale reads [OK]

Hint: Eventual consistency allows temporary stale data [OK]

Common Mistakes:

• Expecting instant update on all nodes
• Confusing update rejection with consistency model
• Assuming data deletion on other nodes

4. A system claims to provide strong consistency but users report seeing outdated data after updates. What is the most likely cause?

medium

A. The system uses synchronous replication correctly.

B. The system is actually using eventual consistency under the hood.

C. Users are refreshing their data too often.

D. The network is too fast causing data to update too quickly.

Solution

1. Step 1: Understand strong consistency guarantees

   Strong consistency guarantees all users see the latest data immediately after update.

2. Step 2: Analyze why outdated data appears

   If users see outdated data, the system likely does not enforce strong consistency, possibly using eventual consistency instead.

3. Final Answer:

   The system is actually using eventual consistency under the hood. -> Option B

4. Quick Check:

   Outdated data means no strong consistency [OK]

Hint: Outdated data means strong consistency is not enforced [OK]

Common Mistakes:

• Blaming network speed for outdated data
• Assuming user refresh frequency causes inconsistency
• Confusing synchronous replication with eventual consistency

5. You are designing a global e-commerce platform. Which consistency model should you choose for the inventory stock count to ensure customers never buy more items than available, and why?

hard

A. Eventual consistency, because it improves performance and availability.

B. No consistency model is needed for inventory data.

C. Strong consistency, because it guarantees all users see the latest stock count immediately.

D. Use eventual consistency with no synchronization.

Solution

1. Step 1: Identify critical data requirements

   Inventory stock count must be accurate to prevent overselling, requiring immediate data correctness.

2. Step 2: Choose consistency model based on requirements

   Strong consistency ensures all users see the latest stock count instantly, preventing overselling.

3. Final Answer:

   Strong consistency, because it guarantees all users see the latest stock count immediately. -> Option C

4. Quick Check:

   Critical data needs strong consistency [OK]

Hint: Critical data needs strong consistency for accuracy [OK]

Common Mistakes:

• Choosing eventual consistency for critical stock data
• Ignoring consistency needs for inventory
• Assuming no consistency is acceptable