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

Test your understanding

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

AStrong Consistency Service

BReplication Queue

CLoad Balancer

DReplica 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.