Bird
Raised Fist0

CAP Theorem - Consistency, Availability, Partition Tolerance in Real Systems

HLDmediumInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/7
API Gateway (Envoy)

Receives client update request

Validates and routes request to Load Balancer

Protocol:HTTP/2
BeforeClient request is at the network edge, unprocessed
AfterRequest is authenticated and forwarded to Load Balancer
Load Balancer (NGINX)

Distributes request to backend services

Forwards request to Redis cache for quick read

Protocol:HTTP/1.1
BeforeRequest is authenticated and ready for routing
AfterRequest sent to Redis to check cached data
Redis

Checks for cached user data

Cache miss triggers read from Cassandra DB

Protocol:Redis GET
BeforeNo cached data for requested user
AfterCache miss detected, triggers DB read
Cassandra

Reads user data for consistency

Returns latest data to Redis for caching

Protocol:CQL Read
BeforeCache miss triggered DB read
AfterLatest user data fetched and sent to Redis
Redis

Caches fresh user data

Prepares for quick future reads

Protocol:Redis SET
BeforeFresh data received from Cassandra
AfterUser data cached for subsequent requests
Load Balancer (NGINX)

Sends update command to Kafka

Ensures partition tolerance via async messaging

Protocol:Kafka Publish
BeforeUser data updated in cache and DB
AfterUpdate event published to Kafka for downstream
Kafka

Durably stores update event

Enables partition tolerance and eventual consistency

Protocol:Kafka Internal
BeforeUpdate event received from Load Balancer
AfterEvent durably stored and ready for consumers
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────────┐
│  API Gateway (Envoy)  │
└────────────┬──────────┘
             │ HTTP/2
             ▼
┌───────────────────────┐
│  Load Balancer (NGINX)│
└────────────┬──────────┘
             │ HTTP/1.1
             ▼
┌────────────┐           ┌────────────┐
│   Redis    │◄──────────│ Cassandra  │
│   Cache    │  Redis GET│    DB      │
└─────┬──────┘           └─────┬──────┘
      │                      │
      │ Redis SET            │ CQL Write
      ▼                      ▼
┌───────────────┐        ┌───────────┐
│    Kafka      │◄───────│ Load Bal. │
│   Queue       │ Kafka │           │
└───────────────┘Publish└───────────┘
Design Rationale

This architecture demonstrates the CAP theorem trade-offs in a real system. The API Gateway and Load Balancer handle client requests ensuring availability and routing. Redis cache provides fast reads but may serve stale data, trading consistency for speed. Cassandra prioritizes availability and partition tolerance, allowing writes even during network splits but with eventual consistency. Kafka acts as a durable message queue ensuring partition tolerance by asynchronously replicating update events. The flow shows how consistency is relaxed in favor of availability and partition tolerance, illustrating practical CAP trade-offs in distributed systems.

Primary Focus

✓

Practice

(1/5)
1. A microservice calls a downstream service that occasionally fails or responds slowly. To prevent cascading failures and allow quick recovery, which component should be introduced?
easy
A. Implement a circuit breaker to stop calls after failure threshold is reached
B. Use a retry mechanism with exponential backoff on every request
C. Add a load balancer to distribute requests evenly across instances
D. Use a message queue to buffer all requests asynchronously

Solution

  1. Step 1: Identify failure containment mechanism

    Retries alone (A) can worsen cascading failures by increasing load; load balancers (C) distribute load but don't prevent failures; message queues (D) buffer but don't stop calls to failing services.

  2. Step 2: Recognize circuit breaker role

    Circuit breakers (B) detect failure thresholds and open to stop calls, preventing cascading failures and allowing recovery.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Circuit breaker stops calls after failures to prevent cascade [check]
Hint: Circuit breaker stops calls after failures to prevent cascade [OK]
Common Mistakes:
2. If the vector storage layer loses durability guarantees (e.g., no persistent writes), what exact failure occurs during a node crash?
medium
A. The HNSW index rebuilds automatically with stale data but no data loss
B. Queries return incorrect nearest neighbors due to corrupted index links
C. Recent vector inserts are lost, causing missing search results for those vectors
D. The system falls back to brute-force search with no performance impact

Solution

  1. Step 1: Understand durability impact on vector storage

    Without persistence, recent inserts are lost on crash, but existing index data remains intact.

  2. Step 2: Analyze index rebuild behavior

    HNSW index rebuilds from last persisted snapshot, so it uses stale data but does not corrupt links.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Index rebuild uses stale data; recent inserts lost but no corruption [check]
Hint: No durability -> stale index rebuild, recent inserts lost [check]
Common Mistakes:
3. Without the distributed consensus component (e.g., Raft), what exact failure occurs during a primary node crash in GitHub's database cluster?
medium
A. Primary node continues accepting writes, causing split-brain and data divergence
B. Backup snapshots fail to trigger, preventing recovery from crash
C. Failover blocks indefinitely waiting for leader election, causing downtime
D. Clients experience immediate failover with stale data reads

Solution

  1. Step 1: Role of consensus in failover

    Consensus prevents split-brain by ensuring only one leader accepts writes.

  2. Step 2: Consequence of missing consensus

    Without consensus, multiple nodes may accept writes simultaneously, causing data divergence.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Consensus absence leads to split-brain and inconsistent writes [check]
Hint: No consensus -> split-brain and data divergence
Common Mistakes:
4. Without the use of consistent hashing in a distributed cache, what failure scenario occurs when a node is removed?
medium
A. Only the keys assigned to the removed node are lost permanently
B. The system automatically replicates keys to other nodes without delay
C. Clients continue to query the removed node causing request failures
D. All keys must be remapped causing a cache-wide performance degradation and potential cache stampede

Solution

  1. Step 1: Understand modular hashing failure on node removal

    Modular hashing requires remapping all keys, causing performance degradation and cache misses.

  2. Step 2: Evaluate options

    The system automatically replicates keys to other nodes without delay incorrectly assumes automatic replication without delay; Clients continue to query the removed node causing request failures is invalid as clients rely on updated routing.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Without consistent hashing, remapping causes cache stampede, no instant replication [check]
Hint: No consistent hashing -> full remap, cache stampede risk [check]
Common Mistakes:
5. If Zookeeper's session timeout mechanism fails to detect a crashed leader node promptly, what is the most likely failure observed in the leader election process?
medium
A. Multiple nodes simultaneously assume leadership causing split-brain
B. Leader election proceeds normally due to backup leader election mechanism
C. Followers wait indefinitely for leader node removal, blocking leader election
D. Clients receive stale configuration but leader election continues

Solution

  1. Step 1: Understand session timeout role

    Session timeout detects leader failure by ephemeral node removal.

  2. Step 2: Failure of timeout detection

    If timeout fails, ephemeral node remains, so followers do not start election; no split-brain occurs.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Backup election mechanisms prevent split-brain despite timeout failure [check]
Hint: Session timeout failure -> ephemeral node stays -> no immediate election [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