Bird
Raised Fist0

Consensus Algorithms - Paxos and Raft Intuition for Interviews

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

Receive client update request

Client sends a state update command to proxy

Protocol:WebSocket
BeforeClient has a new state update command to send
AfterProxy Layer has received the command and prepares to forward
Consensus Nodes

Forward command to leader node

Proxy forwards command to current leader among consensus nodes

Protocol:Raft RPC
BeforeConsensus nodes await new commands from proxy
AfterLeader node receives command and starts consensus
Leader Election Module

Confirm leader status

Leader Election Module verifies leader node is active

Protocol:Internal RPC
BeforeLeader node status uncertain after network changes
AfterLeader node confirmed active and coordinates consensus
Distributed Log & State Machine Layer

Append command to distributed log

Leader appends command to replicated log and replicates to followers

Protocol:Network Layer (gRPC)
BeforeDistributed log contains previous committed commands
AfterNew command durably appended and replicated to followers
Distributed Log & State Machine Layer

Apply command to state machine

Once replicated, command is applied to state machine to update state

Protocol:Internal
BeforeState machine reflects state before new command
AfterState machine updated with new command's effect
Consensus Nodes

Send success response to client proxy

Leader notifies proxy that command is committed

Protocol:Raft RPC
BeforeProxy waiting for commit confirmation
AfterProxy receives confirmation and prepares client response
Client Proxy Layer

Respond to client

Proxy sends success acknowledgment to client

Protocol:WebSocket
BeforeProxy has commit confirmation from leader
AfterClient receives confirmation that update is committed
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────────┐
│   Client Proxy Layer  │
└─────────────┬─────────┘
              │ WebSocket
              ▼
┌───────────────────────┐
│    Consensus Nodes    │
│  (Leader & Followers) │
└───────┬─────┬─────────┘
        │     │ Raft RPC
        │     ▼
        │  ┌───────────────────────┐
        │  │ Leader Election Mod   │
        │  └─────────┬─────────────┘
        │            │ Internal RPC
        ▼            ▼
┌──────────────────────────────────────┐
│ Distributed Log & State Machine Layer│
│  (Durable log, apply cmds to State M)│
└──────────────────────────────────────┘
              ▲
              │ Network Layer (gRPC)
              │
              └───────────────────────────┐
                                          │
                                          ▼
Design Rationale

This architecture diagram illustrates the flow of a client state update through a consensus system using Paxos or Raft. The Client Proxy Layer receives the request and forwards it to the Consensus Nodes, where a leader coordinates agreement. The Leader Election Module ensures the leader is active to avoid split-brain scenarios. The command is appended to the Distributed Log and replicated to followers via the Network Layer using gRPC. Once committed, the command is applied to the State Machine, ensuring consistent state across nodes. Finally, the leader notifies the proxy, which responds to the client. This vertical flow highlights the critical role of leader election and log replication in achieving consensus and fault tolerance.

Primary Focus

✓

Practice

(1/5)
1. In a distributed file system request flow, at Step 4 the Metadata Server responds to the client with block locations. What state does the client hold immediately after Step 4?
easy
A. Client has cached file data blocks locally
B. Client holds metadata including block locations but has not contacted Data Nodes yet
C. Client has updated the Metadata Server with new file writes
D. Client has established persistent connections to all Data Nodes

Solution

  1. Step 1: Trace Step 4 response

    At Step 4, Metadata Server returns block locations (metadata) to the client; client does not yet have file data.

  2. Step 2: Confirm client state

    Client holds metadata (block locations) but must contact Data Nodes separately to read/write data blocks.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Client holds metadata, not data, immediately after Step 4 [check]
Hint: Client gets block locations before contacting Data Nodes [check]
Common Mistakes:
2. If the Bloom filter's hash functions are not independent and produce correlated outputs, what is the exact failure mode observed?
medium
A. The bit array will saturate quickly causing excessive false positives and reduced filter effectiveness
B. The filter will have false negatives, incorrectly rejecting existing members
C. The false positive rate increases beyond the expected theoretical rate
D. Insertions will fail silently without updating the bit array

Solution

  1. Step 1: Understand hash function independence role

    Independent hash functions distribute bits uniformly; correlated hashes cause clustering.

  2. Step 2: Trace effect of correlated hashes

    Correlated hashes set overlapping bits, saturating the bit array faster, increasing false positives and reducing filter effectiveness.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Correlated hashes cause bit array saturation, raising false positives [check]
Hint: Correlated hashes cause bit array saturation and false positives [check]
Common Mistakes:
3. For a file sync system supporting offline edits and conflict resolution, which architecture best balances consistency and user experience?
medium
A. Client-side version vectors with eventual consistency and conflict-free replicated data types (CRDTs)
B. Centralized locking server that serializes all file writes to prevent conflicts
C. Synchronous replication to a single master server with immediate conflict rejection
D. Periodic full file re-uploads with server-side merge on conflict detection

Solution

  1. Step 1: Analyze offline edits and conflict resolution needs

    Offline edits require clients to work independently and resolve conflicts later without blocking user actions.

  2. Step 2: Evaluate architectures

    Centralized locking blocks offline use; synchronous replication blocks writes; periodic full re-uploads waste bandwidth and delay merges; client-side version vectors with CRDTs enable eventual consistency and seamless conflict resolution.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    CRDTs enable offline edits with eventual consistency [check]
Hint: CRDTs enable offline edits and conflict-free merges [check]
Common Mistakes:
4. For a system requiring globally unique IDs with high throughput and low latency, which approach is best considering the trade-offs of coordination overhead and ID ordering?
medium
A. Use a distributed consensus protocol (e.g., Paxos) to assign IDs synchronously
B. Use a database auto-increment primary key with sharding
C. Use a centralized Ticket Server allocating ID blocks to clients for local use
D. Use client-generated UUIDs combined with a timestamp prefix

Solution

  1. Step 1: Evaluate coordination overhead

    Consensus (A) ensures strong consistency but adds latency and limits throughput; DB auto-increment with sharding (D) risks collisions and complex coordination.

  2. Step 2: Assess ordering and uniqueness

    UUIDs (C) are unique but unordered and can cause issues in ordered systems; Ticket Server (B) balances uniqueness, ordering, and throughput by allocating ID blocks.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Ticket Server -> high throughput, low latency, ordered IDs [check]
Hint: Centralized block allocation beats consensus and UUIDs for throughput [check]
Common Mistakes:
5. At 10x scale of concurrent users editing documents globally, which component is most likely to become the bottleneck first, and why?
hard
A. The client UI, because rendering many remote edits overwhelms browser resources
B. The persistent storage layer, because write throughput cannot keep up with operation volume
C. The network layer, because increased latency causes operation reordering and conflicts
D. The OT engine, because it maintains stateful transformation buffers that grow with concurrent edits

Solution

  1. Step 1: Analyze scaling challenges of OT engine

    The OT engine maintains stateful buffers and transforms operations in-memory, which grow with the number of concurrent edits and users.

  2. Step 2: Compare with other components

    Persistent storage can be sharded and scaled; network latency affects but does not bottleneck first; client UI scales per user, not globally.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    OT engine's stateful buffers grow with concurrency, limiting scale first [check]
Hint: OT engine buffers grow with concurrency, limiting scale first [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