Bird
Raised Fist0

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

HLDmediumInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🎯
Consistency Models - Strong, Eventual, Causal, Read-Your-Writes Explained
45 min · senior
senior

You are designing a distributed data storage and retrieval system for a 50 million daily active user (DAU) social media startup. The system must support different consistency models (Strong, Eventual, Causal, Read-Your-Writes) to cater to various product features such as timelines, messaging, and notifications. The system must handle high throughput and low latency with P99 read latency under 200ms globally. Data must be encrypted at rest and in transit. Users expect offline access with eventual sync when reconnecting. The system should allow clients to select consistency guarantees per operation.

Constraints
  • 50 million DAU generating 10 billion reads and 2 billion writes daily
  • End-to-end encryption required for user data at rest and in transit
  • P99 read latency must be under 200ms globally
  • Support offline client operations with eventual synchronization
  • Allow clients to specify consistency model per request
  • Global multi-region deployment with data locality considerations
📋
Guided Steps
1/5
Step 1
Define consistency models and their trade-offs
Explain the differences between Strong, Eventual, Causal, and Read-Your-Writes consistency models and when each is appropriate.
💡 Hint
Consider latency, availability, and user experience trade-offs for each model.
Key Decision
Use Strong consistency with linearizable reads/writes via Apache Cassandra with lightweight transactions for critical data, Eventual consistency with DynamoDB Global Tables for high availability, Causal consistency via Apache Pulsar with vector clocks for ordering, and Read-Your-Writes consistency using client-side session tokens stored in Redis.
Interviewer Expectation
Mid: Names consistency models and basic trade-offs. Senior: Explains how Cassandra LWT enables linearizability, why DynamoDB eventual consistency improves availability, how Pulsar vector clocks track causality, and Redis session tokens enforce read-your-writes per client.
⚠️Common Wrong Answer
Mixing eventual consistency everywhere without explaining user impact - leads to confusing UX and data anomalies.
Step 2
Design data storage and replication strategy
How will you store and replicate data globally to support these consistency models under the given scale and latency constraints?
💡 Hint
Think about partition keys, replication protocols, and multi-region data placement.
Key Decision
Use Apache Cassandra with conversation_id as partition key for strong consistency partitions, DynamoDB Global Tables for eventual consistency with multi-region replication, and Apache Pulsar for causal ordering with topic partitioning by user_id. Reject MongoDB due to lack of linearizable transactions at scale.
Interviewer Expectation
Mid: Names Cassandra and DynamoDB for storage. Senior: Explains partition key choice for locality and linearizable writes, why MongoDB fails at scale for strong consistency, and how Pulsar topics enforce causal ordering.
⚠️Common Wrong Answer
Using a single global database without partitioning - causes high latency and write bottlenecks.
Step 3
Implement offline support and synchronization
How will the system support offline client operations and synchronize data upon reconnection while preserving consistency guarantees?
💡 Hint
Consider client-side state, conflict detection, and reconciliation mechanisms.
Key Decision
Use client-side local storage with conflict-free replicated data types (CRDTs) for eventual consistency offline edits, synchronize via Kafka topics keyed by user_id for ordered delivery, and use Redis for session tokens to enforce read-your-writes consistency during sync.
Interviewer Expectation
Mid: Mentions local storage and sync queues. Senior: Details CRDTs for conflict-free merges, Kafka partitioning for ordered sync, and Redis session tokens to maintain read-your-writes guarantees.
⚠️Common Wrong Answer
Relying on last-write-wins without conflict resolution - leads to data loss and user confusion.
Step 4
Design API endpoints for consistency model selection
Design 3 core API endpoints that allow clients to write data, read data with a specified consistency model, and acknowledge synchronization status.
💡 Hint
Think about how clients specify consistency, how offline writes are submitted, and how sync acknowledgments are handled.
Key Decision
POST /data/write with consistency param (strong, eventual, causal, read-your-writes), GET /data/read with consistency param and session token for read-your-writes, POST /sync/ack to acknowledge successful offline sync; use gRPC for low latency and protobuf for schema enforcement.
Interviewer Expectation
Mid: Defines basic read/write endpoints. Senior: Explains consistency param usage, session token for read-your-writes, offline sync ack endpoint, and choice of gRPC for performance.
⚠️Common Wrong Answer
Single generic read/write API without consistency parameter - forces one-size-fits-all and poor UX.
Step 5
Ensure encryption and security compliance
How will you enforce encryption at rest and in transit while maintaining performance and consistency guarantees?
💡 Hint
Consider TLS, KMS, and encryption integration with storage and messaging layers.
Key Decision
Use TLS 1.3 for all client-server and inter-service communication, AWS KMS for envelope encryption keys integrated with DynamoDB and Cassandra, and Apache Pulsar with TLS and token-based authentication; reject unencrypted Kafka due to compliance risks.
Interviewer Expectation
Mid: Mentions TLS and encryption. Senior: Details KMS integration with storage, envelope encryption for minimal latency impact, and Pulsar security features.
⚠️Common Wrong Answer
Ignoring encryption in messaging layer - exposes data in transit and violates compliance.
🔌
API Design Challenge
Sketch 3 core API endpoints that enable clients to write data, read data with specified consistency, and acknowledge synchronization status.
Hints
  • How does the client specify the desired consistency model in the read/write API?
  • How does the system handle offline writes and later synchronization?
  • How does the client acknowledge successful data sync or conflict resolution?
📊
Scoring Rubric
▼ Show
Must Have - 60%
  • Clear explanation of consistency models with real tech examples
  • Partition key strategy for Cassandra and Kafka to ensure ordering and locality
  • Offline support design with conflict resolution using CRDTs and sync mechanisms
  • API design allowing clients to specify consistency per request
  • Encryption at rest and in transit integrated with storage and messaging
Good to Have - 30%
  • Mid: Names Kafka. Senior: Explains conversation_id partition key and ordering guarantee
Bonus - 10%
    Anti-patterns to Avoid
    ✅
    Model Answer
    ▼ Reveal

    This design explains and implements Strong, Eventual, Causal, and Read-Your-Writes consistency models using specific technologies to meet scale, latency, and security requirements for a 50M DAU social media startup. It includes global data replication, offline support with conflict resolution, and flexible API design for client-specified consistency.

    Key Decisions
    • Use Apache Cassandra with conversation_id as partition key to enable linearizable strong consistency via lightweight transactions for critical data.
    • Employ DynamoDB Global Tables for eventual consistency with multi-region replication to achieve high availability and low latency.
    • Leverage Apache Pulsar with vector clocks and topic partitioning by user_id to enforce causal consistency and message ordering.
    • Implement Redis session tokens to maintain read-your-writes consistency per client session during reads and sync.
    • Use Kafka topics keyed by user_id to order offline client edits and enable conflict-free synchronization upon reconnection.
    • Enforce TLS 1.3 for all client-server and inter-service communication and integrate AWS KMS for envelope encryption keys with storage systems.
    • Design APIs with gRPC and protobuf, including a consistency parameter in read/write endpoints and a sync acknowledgment endpoint to support offline operations.
    • Utilize client-side CRDTs to allow offline edits that merge conflict-free when synchronized.
    • Apache Cassandra with conversation_id partition key for strong consistency linearizable writes
    • DynamoDB Global Tables for multi-region eventual consistency with low latency
    • Apache Pulsar with vector clocks for causal consistency and ordered message delivery
    • Redis session tokens to enforce read-your-writes consistency per client session
    • Kafka topics keyed by user_id for offline sync ordered delivery and conflict resolution
    • TLS 1.3 for encryption in transit and AWS KMS for envelope encryption at rest
    • gRPC with protobuf for low latency, schema enforcement, and consistency param in APIs
    • Client-side CRDTs for offline edits enabling conflict-free merges upon sync

    Practice

    (1/5)
    1. A web application requires real-time bidirectional communication with low latency and minimal overhead for interactive gaming. Which technology best fits this requirement?
    easy
    A. Use WebSockets because they provide full-duplex communication with low latency suitable for interactive use.
    B. Use Server-Sent Events because they support unidirectional streaming from server to client efficiently.
    C. Use Long Polling because it is simpler to implement and works well for real-time bidirectional communication.
    D. Use HTTP/2 multiplexing as it inherently supports bidirectional streaming without additional protocols.

    Solution

    1. Step 1: Identify communication direction and latency needs

      Interactive gaming requires low latency and bidirectional communication, which Server-Sent Events and Long Polling do not efficiently provide.

    2. Step 2: Evaluate protocol capabilities

      WebSockets provide full-duplex communication with minimal overhead, ideal for real-time interactive applications. HTTP/2 multiplexing is not widely supported for bidirectional streaming in browsers and adds complexity.

    3. Final Answer:

      Option A -> Option A

    4. Quick Check:

      WebSockets enable low-latency bidirectional streams [check]
    Hint: Bidirectional + low latency -> WebSockets [check]
    Common Mistakes:
    2. For adaptive bitrate streaming, which architecture best balances latency and bandwidth efficiency when delivering HLS segments to mobile users with fluctuating network conditions?
    medium
    A. Use a single high-bitrate stream and rely on client buffering to handle fluctuations
    B. Use a fixed medium bitrate stream to avoid complexity of switching
    C. Use multiple bitrate streams segmented into small chunks with client-driven bitrate switching
    D. Use server-driven bitrate adaptation by detecting client bandwidth and pushing segments accordingly

    Solution

    1. Step 1: Understand adaptive bitrate streaming principles

      Client-driven switching with multiple bitrate streams allows clients to adapt quickly to network changes, reducing buffering and wasted bandwidth.

    2. Step 2: Evaluate other options

      Single high-bitrate wastes bandwidth; server-driven adaptation adds latency and complexity; fixed bitrate can't adapt to network variability.

    3. Final Answer:

      Option C -> Option C

    4. Quick Check:

      Client-driven multi-bitrate switching optimizes latency and bandwidth [check]
    Hint: Client controls bitrate switching for best latency and bandwidth [check]
    Common Mistakes:
    3. Without the graph database's relationship index, what exactly breaks during a shortest path query between two nodes?
    medium
    A. The query silently returns empty results without any error indication
    B. The query falls back to scanning all nodes and edges, causing severe latency spikes
    C. The query returns incorrect paths due to stale data in the index
    D. The query crashes the database server due to unhandled exceptions

    Solution

    1. Step 1: Role of relationship index

      The index enables efficient lookup of edges; without it, traversal cannot proceed correctly.

    2. Step 2: Behavior without index

      Queries relying on the index return empty results silently because no edges are found, not errors or scans.

    3. Final Answer:

      Option A -> Option A

    4. Quick Check:

      Missing index causes silent empty results, not crashes or scans [check]
    Hint: Missing index -> silent empty results, no errors or scans [check]
    Common Mistakes:
    4. For a distributed API gateway enforcing rate limits per user, which design is best to handle burst traffic while maintaining consistency?
    medium
    A. Use local token buckets per gateway with periodic token sync and eventual consistency
    B. Use a centralized Redis token bucket shared by all gateways with strong consistency
    C. Use a fixed window counter stored in a distributed cache updated synchronously
    D. Use a leaky bucket implemented in each gateway without synchronization

    Solution

    1. Step 1: Evaluate centralized Redis token bucket

      Strong consistency causes high latency and bottlenecks under burst traffic.

    2. Step 2: Evaluate local token buckets with periodic sync

      Allows burst handling locally with eventual consistency, reducing latency and bottlenecks.

    3. Step 3: Eliminate fixed window and leaky bucket options

      Fixed window counters cause burst spikes; leaky bucket disallows bursts and lacks sync.

    4. Final Answer:

      Option A -> Option A

    5. Quick Check:

      Local token buckets + eventual sync balance burst and consistency [check]
    Hint: Local buckets + sync handle bursts and scale better [OK]
    Common Mistakes:
    5. For a global web service requiring low latency and high availability, which load balancing strategy is best suited to handle user requests across multiple data centers?
    medium
    A. Use DNS round-robin to distribute requests evenly across data centers
    B. Use a global load balancer with health checks and geo-routing capabilities
    C. Use client-side load balancing with hardcoded server IPs in the client app
    D. Use a single centralized load balancer in one data center to route all traffic

    Solution

    1. Step 1: Evaluate DNS round-robin limitations

      DNS round-robin (Use DNS round-robin to distribute requests evenly across data centers) lacks real-time health checks and can send traffic to unhealthy data centers, causing poor availability.

    2. Step 2: Assess global load balancer benefits

      A global load balancer (Use a global load balancer with health checks and geo-routing capabilities) performs health checks and routes users to the nearest healthy data center, optimizing latency and availability.

    3. Step 3: Consider client-side and centralized load balancing drawbacks

      Client-side load balancing (Use client-side load balancing with hardcoded server IPs in the client app) is hard to update and lacks global awareness. A single centralized load balancer (Use a single centralized load balancer in one data center to route all traffic) creates a single point of failure and latency bottleneck.

    4. Final Answer:

      Option B -> Option B

    5. Quick Check:

      Global load balancer with geo-routing optimizes latency and availability [check]
    Hint: Global load balancer routes by health and geography [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