Bird
Raised Fist0

Consistency Models - Strong, Eventual, Causal, Read-Your-Writes Explained

HLDmediumInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/5
Write Frontend

Receive client write request

Client sends a write to update data with strong consistency requested

Protocol:HTTP/REST
BeforeClient has new data to write; no server has processed it yet
AfterWrite Frontend accepted write and forwarded it to Consistency Coordinator
Consistency Coordinator

Apply consistency rules and coordinate write

Coordinator ensures write ordering and consistency model enforcement

Protocol:Internal RPC
BeforeWrite Frontend forwarded write without ordering guarantees
AfterWrite validated and prepared for durable commit to Kafka
Kafka Cluster

Persist write event in ordered log

Write event appended to Kafka partition ensuring order per key

Protocol:Kafka Produce
BeforeWrite event not yet durably stored in Kafka
AfterWrite event durably stored and visible to Kafka consumers
Cassandra DB

Consume Kafka event and update database

Cassandra applies write with configured consistency level (e.g. QUORUM)

Protocol:Kafka Consume + CQL Write
BeforeCassandra holds old data version; write event pending consumption
AfterCassandra updated with new data version consistent with model
Read Frontend

Serve client read request

Read Frontend queries Cassandra with consistency guarantees (e.g. read-your-writes)

Protocol:CQL Read
BeforeClient requests data read after write completion
AfterClient receives data consistent with requested consistency model
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│ Write Frontend│
└───────┬───────┘
        │ HTTP/REST
        ▼
┌───────────────────────┐
│ Consistency Coordinator│
└─────────┬─────────────┘
          │ Kafka Produce
          ▼
    ┌───────────────┐
    │ Kafka Cluster │
    └──────┬────────┘
           │ Kafka Consume
           ▼
    ┌───────────────┐
    │ Cassandra DB  │
    └──────┬────────┘
           │ CQL Read
           ▼
    ┌───────────────┐
    │ Read Frontend │
    └───────────────┘
Design Rationale

This architecture demonstrates how different consistency models are enforced in a distributed system. The Write Frontend receives client writes and forwards them to the Consistency Coordinator, which enforces ordering and consistency rules before committing the write to Kafka. Kafka acts as a durable, ordered log ensuring writes are processed in sequence. Cassandra consumes these events and applies writes with tunable consistency levels, enabling strong, eventual, or causal consistency. Finally, the Read Frontend serves client reads with guarantees such as read-your-writes by querying Cassandra accordingly. This vertical flow highlights how coordination, durable logs, and database consistency settings interplay to provide different consistency semantics transparently to clients.

Primary Focus

✓

Practice

(1/5)
1. In a multi-CDN request flow, at Step 4 the Global Traffic Manager receives a health check failure from CDN Provider A. What is the immediate action taken by the Global Traffic Manager at this step?
easy
A. It marks CDN Provider A as unhealthy and temporarily stops routing new requests to it
B. It sends a notification to the origin server to stop sending content to CDN Provider A
C. It immediately reroutes all new user requests to CDN Provider B without delay
D. It caches the last successful response from CDN Provider A to serve future requests

Solution

  1. Step 1: Understand Global Traffic Manager health check handling

    Upon receiving a health check failure, the manager marks the CDN as unhealthy to prevent routing new requests to it.

  2. Step 2: Eliminate other options

    Immediate rerouting (A) may cause abrupt traffic shifts without grace. Origin server notifications (C) are not part of traffic management. Caching responses (D) is unrelated to health check handling.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Health check failure -> mark CDN unhealthy, stop routing new requests [check]
Hint: Health check failure -> mark CDN unhealthy, pause routing [OK]
Common Mistakes:
2. If the health check module fails to run, what is the exact failure observed in the load balancer's routing behavior?
medium
A. Load balancer reroutes traffic randomly ignoring server health
B. Load balancer blocks all traffic until health checks resume
C. Load balancer routes only to a cached subset of servers marked healthy previously
D. Load balancer continues routing to all servers, including unhealthy ones, causing client errors

Solution

  1. Step 1: Understand health check module role

    Health checks detect unhealthy servers; without them, no updates occur to remove bad servers.

  2. Step 2: Trace routing behavior without health checks

    Load balancer routes to all servers indiscriminately, including unhealthy ones, causing client errors.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    No health checks -> no removal of unhealthy servers -> client errors [check]
Hint: No health checks means no unhealthy server removal [check]
Common Mistakes:
3. For a system requiring per-user rate limits with minimal latency, which architecture is better and why?
medium
A. Service-layer counters with no database persistence for simplicity
B. Centralized database counters updated synchronously on every request for accuracy
C. Client-side counters with server verification on every request for trustworthiness
D. Distributed in-memory counters at the API Gateway with periodic async database sync for scalability

Solution

  1. Step 1: Compare latency and scalability

    Synchronous DB updates cause high latency and DB bottlenecks; client-side counters are untrustworthy; service-layer without persistence risks data loss.

  2. Step 2: Evaluate distributed in-memory counters

    API Gateway counters provide low latency and scalability; async DB sync ensures eventual consistency and durability.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Distributed in-memory counters balance latency and scalability [check]
Hint: Async DB sync + in-memory counters = low latency + scalability [check]
Common Mistakes:
4. At 10x scale, which component in a client-server system handling persistent WebSocket connections is most likely to fail first, and why?
hard
A. Database server, because increased writes overwhelm disk I/O
B. Load balancer, because it cannot efficiently distribute stateful WebSocket connections
C. Cache server, because memory limits are exceeded by session data
D. WebSocket server, because it maintains stateful connections that cannot be easily sharded or moved

Solution

  1. Step 1: Identify stateful component bottleneck

    WebSocket servers maintain persistent connections tied to server memory, limiting horizontal scaling.

  2. Step 2: Compare other components

    Databases and caches can be scaled with sharding or replication; load balancers can distribute stateless HTTP requests but struggle with sticky WebSocket sessions.

  3. Step 3: Understand why WebSocket servers fail first

    Because connections are stateful and bound to specific servers, scaling requires complex connection migration or results in overload.

  4. Final Answer:

    Option D -> Option D

  5. Quick Check:

    Stateful WebSocket servers bottleneck at scale due to connection affinity [check]
Hint: Stateful WebSocket servers bottleneck first at scale [check]
Common Mistakes:
5. At 10x scale, which component in a Kafka-like distributed message queue is most likely to fail first, and why?
hard
A. The Kafka brokers, because partition leaders become overloaded with write and replication traffic
B. The consumer clients, because they cannot keep up with increased message consumption rates
C. The ZooKeeper ensemble, due to coordination overhead and leader election delays under heavy load
D. The network switches, due to increased packet loss under high throughput

Solution

  1. Step 1: Identify bottlenecks at 10x scale

    Network switches (A) scale with hardware upgrades; ZooKeeper (C) handles coordination but is lightweight compared to brokers; consumers (D) can be scaled horizontally.

  2. Step 2: Kafka broker partition leader overload

    Partition leaders handle all writes and replication for their partitions; at 10x scale, leaders become hotspots causing CPU, disk, and network saturation, leading to failures.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Partition leaders overloaded -> broker failure first at scale [check]
Hint: Partition leaders handle all writes -> overload first at scale [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard