Bird
Raised Fist0

Data Replication Strategies - Synchronous vs Asynchronous, Quorum Writes

HLDmediumInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/6
Client API Layer

Receives write request from client

Client sends data to be replicated with quorum write requirement

Protocol:HTTP/REST
BeforeClient has data ready to write but no replicas have it
AfterWrite request forwarded to Replication Coordinator
Replication Coordinator

Initiates replication to Replica Nodes

Sends write commands to multiple Replica Nodes using quorum strategy

Protocol:gRPC
BeforeNo replicas have acknowledged the write
AfterWrite commands sent to Replica Nodes; waiting for quorum acks
Replica Node

Commits write to Persistent Storage

Each replica writes data durably and sends ack back

Protocol:TCP
BeforeReplica Node has not stored the new data
AfterReplica Node has durably stored data and sent ack
Replication Coordinator

Collects acknowledgments from Replica Nodes

Waits until quorum of replicas confirm write success

Protocol:gRPC
BeforeSome replicas have acknowledged, quorum not yet reached
AfterQuorum reached; write considered successful
Client API Layer

Returns success response to client

Client informed that write is durable per quorum policy

Protocol:HTTP/REST
BeforeWrite not yet confirmed to client
AfterClient receives confirmation of successful write
Monitoring & Alerting

Monitors replication health and latency

Tracks replication lag and alerts if quorum not met timely

Protocol:Internal Metrics
BeforeNo alerts active; replication ongoing
AfterAlerts triggered if replication delays or failures detected
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────────┐
│    Client API Layer   │
└─────────────┬─────────┘
              │ HTTP/REST Write Req
              ▼
┌───────────────────────────────┐
│     Replication Coordinator    │
│  (manages sync/async/quorum)  │
└─────────────┬─────────────────┘
              │ Replication Msg (gRPC)
              ▼
┌───────────────┐
│  Replica Node │
│  (Node 1)     │
└──────┬────────┘
       │ Write Commit (TCP)
       ▼
┌───────────────┐
│ Persistent    │
│ Storage       │
└───────────────┘
       ▲
       │ Write Ack (TCP)
┌──────┴────────┐
│  Replica Node │
│  (Node 2)     │
└──────┬────────┘
       │ Write Commit (TCP)
       ▼
┌───────────────┐
│ Persistent    │
│ Storage       │
└───────────────┘
       ▲
       │ Write Ack (TCP)
       ▼
┌───────────────────────────────┐
│    Monitoring & Alerting       │
│  (tracks replication health)   │
└───────────────────────────────┘
Design Rationale

This architecture illustrates how a write request flows from the Client API Layer to the Replication Coordinator, which manages replication using a quorum write strategy. The coordinator sends write commands to multiple Replica Nodes, each committing data to their Persistent Storage. The coordinator waits for acknowledgments from a quorum of replicas before confirming success back to the client. Meanwhile, Monitoring & Alerting continuously tracks replication health and latency to detect failures or delays. This design balances durability and availability by requiring a quorum of replicas to confirm writes, ensuring data consistency without waiting for all replicas synchronously. The vertical flow emphasizes the sequential steps and clear component responsibilities in the replication process.

Primary Focus

✓

Practice

(1/5)
1. A distributed key-value store must evenly distribute keys across nodes and handle node failures without massive data reshuffling. Which component primarily enables this?
easy
A. Gossip protocol to propagate membership and failure information
B. Vector clocks to resolve conflicting versions of data
C. Consistent hashing to assign keys to nodes with minimal remapping
D. Quorum-based replication to ensure data durability

Solution

  1. Step 1: Identify the role of consistent hashing

    Consistent hashing distributes keys to nodes such that when nodes join or leave, only a small subset of keys need reassignment, minimizing reshuffling.

  2. Step 2: Eliminate other components

    Vector clocks handle version conflicts but do not distribute keys. Gossip protocol manages cluster membership but not key distribution. Quorum replication ensures durability but does not affect key assignment.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Consistent hashing minimizes key remapping on node changes [check]
Hint: Consistent hashing minimizes key remapping on node changes [OK]
Common Mistakes:
2. A distributed task scheduler must support millions of scheduled jobs with varying priorities and ensure tasks are executed exactly once. Which component is best suited to manage task ordering and priority under these constraints?
easy
A. A distributed priority queue with partitioned shards
B. A relational database with indexed priority columns
C. A simple FIFO message queue like RabbitMQ without priority support
D. A cron job scheduler running independently on each node

Solution

  1. Step 1: Identify priority and scale requirements

    A relational DB (A) struggles with high write throughput and priority ordering at scale; simple FIFO queues (C) lack priority support; cron jobs (D) do not coordinate distributed execution or priority.

  2. Step 2: Evaluate distributed priority queue

    A distributed priority queue with partitioned shards (B) can scale horizontally, maintain priority ordering per shard, and support exactly-once execution semantics.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Distributed priority queue shards scale and preserve ordering [check]
Hint: Distributed priority queues scale and order tasks by priority [check]
Common Mistakes:
3. If the Progress Worker crashes before persisting a user's video watch progress, what is the exact failure observed by the user when they resume the course?
medium
A. User sees progress reset to zero and must rewatch videos from the start
B. User's progress appears stuck at last persisted checkpoint, missing recent watch time
C. User receives an error message preventing course continuation until retry
D. User's progress is duplicated causing certificate issuance errors

Solution

  1. Step 1: Trace failure impact of Progress Worker crash

    Progress Worker crash before persistence means recent watch time is lost.

  2. Step 2: Evaluate user experience on resume

    System detects missing progress update and returns error preventing continuation (User receives an error message preventing course continuation until retry), rather than silently resetting or duplicating progress.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Crash causes error blocking course continuation until retry [check]
Hint: Crash blocks progress update, user sees error [OK]
Common Mistakes:
4. If the Bloom filter component is removed from the system, what exact failure occurs during key lookups?
medium
A. Every key lookup hits the backend, causing increased latency and possible backend saturation
B. The system returns false negatives, missing existing keys due to lack of filtering
C. Backend database rejects all queries due to overload, causing 503 errors
D. The system returns false positives, incorrectly indicating keys exist

Solution

  1. Step 1: Understand Bloom filter removal impact

    Without Bloom filters, no pre-filtering occurs, so all lookups go to backend.

  2. Step 2: Analyze failure modes

    Backend overload (A) is possible but not guaranteed. Increased latency (B) is true but not a failure mode. False positives (D) come from Bloom filters, not their absence. False negatives (C) occur if system relies on Bloom filter to avoid missing keys.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Without Bloom filter, system risks missing keys due to no probabilistic filtering [check]
Hint: No Bloom filter means missing keys, false negatives appear [check]
Common Mistakes:
5. At 10x current scale, which component in TikTok's architecture is most likely to fail first and why?
hard
A. The WebSocket servers maintaining live connections, since stateful connections cannot be easily sharded
B. The relational database storing user profiles, due to write amplification from frequent updates
C. The Feed Ranking Service, as it requires low-latency access to large user history data causing memory bottlenecks
D. The video transcoding cluster, because CPU-intensive jobs cannot be parallelized beyond a limit

Solution

  1. Step 1: Analyze stateful connection scaling

    WebSocket servers (D) hold state per connection; scaling requires complex connection migration or sticky sessions.

  2. Step 2: Compare other bottlenecks

    Relational DB (A) can be sharded; transcoding (B) parallelizes; Feed Ranking (C) uses caching and sharding.

  3. Step 3: Identify first failure point

    WebSocket servers hit connection limits first due to stateful nature and limited horizontal scaling.

  4. Final Answer:

    Option A -> Option A

  5. Quick Check:

    Stateful WebSocket servers bottleneck first due to connection affinity [check]
Hint: Stateful WebSocket servers limit horizontal scaling first [OK]
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