Bird
Raised Fist0

Design WhatsApp - Real-Time Chat, Delivery Receipts, End-to-End Encryption

HLDhardInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/7
WebSocket Gateway

Receive encrypted message from Alice's client

Accepts WebSocket frame containing encrypted payload

Protocol:WebSocket
BeforeAlice's client has encrypted message ready to send
AfterEncrypted message received and forwarded to Message Processor
Message Processor

Validate and enqueue message to Kafka

Checks message format, attaches metadata, publishes to Kafka topic

Protocol:Kafka
BeforeEncrypted message is in Message Processor memory
AfterMessage durably committed to Kafka. UI shows single grey tick
Kafka Cluster

Store and deliver message to downstream consumers

Keeps message ordered by conversation ID, delivers to storage and delivery

Protocol:Kafka
BeforeMessage is committed in Kafka partition
AfterMessage available for Cassandra Storage Cl. and Notification Service
Cassandra Storage Cl.

Persist message and delivery receipt

Writes encrypted message and initial delivery receipt to DB

Protocol:CQL
BeforeMessage available from Kafka for storage
AfterMessage and receipt durably stored for history and sync
Presence Service

Check Bob's online status

Queries Redis cache for Bob's presence key

Protocol:Redis GET
BeforeBob's presence status unknown to delivery system
AfterBob marked as offline in Presence Service
Notification Service

Send push notification to Bob's device

Triggers push via APNs/FCM to notify Bob of new message

Protocol:Push
BeforeBob offline, message stored but not delivered live
AfterPush notification sent to Bob's device for message alert
Key Management Service

Provide encryption keys for message decryption

Supplies Bob's device with keys to decrypt message securely

Protocol:Secure API
BeforeBob's device has encrypted message but no keys
AfterBob's device obtains keys to decrypt and read message
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────────┐
│   WebSocket Gateway   │
└─────────────┬─────────┘
              │ WebSocket
              ▼
┌───────────────────────┐
│   Message Processor   │
└─────────────┬─────────┘
              │ Kafka
              ▼
┌───────────────────────┐
│    Kafka Cluster      │
└─────────────┬─────────┘
              │ Kafka
              ▼
┌───────────────────────┐
│ Cassandra Storage Cl. │
└─────────────┬─────────┘
              │ CQL
              ▼
┌───────────────────────┐
│ Notification Service  │
└─────────────┬─────────┘
              │ Push
              ▼
┌───────────────────────┐
│   Presence Service    │
└─────────────┬─────────┘
              │ Redis GET
              ▼
┌───────────────────────┐
│ Key Management Service│
└───────────────────────┘
Design Rationale

This architecture shows a vertical flow from client to storage and notification. The WebSocket Gateway accepts encrypted messages from Alice, forwarding them to the Message Processor, which validates and publishes them to Kafka for durability and ordering. Kafka acts as a durable queue, feeding Cassandra for persistent storage and the Notification Service for offline delivery. The Presence Service uses Redis to check if Bob is online; if offline, Notification Service triggers push notifications. The Key Management Service ensures end-to-end encryption by securely providing decryption keys to Bob's device. This design balances real-time delivery with offline reliability and strong encryption, using asynchronous Kafka queues and presence checks to optimize message flow.

Primary Focus

✓

Practice

(1/5)
1. In the deployment system request flow, at Step 4 the Canary Controller evaluates metrics from the new version. What happens if error rates exceed the threshold at this step?
easy
A. Canary Controller immediately promotes the new version to 100% traffic
B. Canary Controller triggers automatic rollback to previous stable version
C. Canary Controller ignores errors and continues increasing traffic
D. Canary Controller disables feature flags for the new version

Solution

  1. Step 1: Understand Step 4 role

    At Step 4, Canary Controller monitors metrics to decide if rollout continues or aborts.

  2. Step 2: Analyze error threshold breach

    If error rates exceed threshold, rollback is triggered to prevent faulty version promotion.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Canary Controller triggers rollback on error threshold breach [check]
Hint: Canary aborts rollout and rolls back on high error rates [OK]
Common Mistakes:
2. A customer support bot must handle 10,000 concurrent user queries with minimal latency and ensure fallback to human agents when intent classification confidence is low. Which component is best suited to manage the fallback routing reliably?
easy
A. A relational database storing fallback requests synchronously
B. An in-memory cache storing fallback intents temporarily
C. A REST API endpoint directly invoking human agent notification
D. A message queue system decoupling intent classification from fallback processing

Solution

  1. Step 1: Identify fallback routing requirements

    The fallback must be reliable and decoupled from real-time intent classification to avoid blocking user queries.

  2. Step 2: Evaluate component suitability

    A message queue decouples processing, enabling asynchronous fallback handling and retry mechanisms. Relational DB synchronous writes (A) cause latency. REST API direct calls (C) block the main flow. In-memory cache (D) lacks durability and reliability.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Message queue decouples and buffers fallback reliably [check]
Hint: Decouple fallback with queues for async reliability [check]
Common Mistakes:
3. For a leaderboard system requiring global ranking with millions of concurrent updates, which architecture is best to ensure low latency and eventual consistency?
medium
A. Use a single Redis instance with sorted sets and synchronous writes
B. Store all scores in a distributed SQL database with strong consistency
C. Partition leaderboard by user region with multiple Redis clusters and merge results asynchronously
D. Use a NoSQL store with eventual consistency and batch ranking computation

Solution

  1. Step 1: Evaluate single Redis instance

    Single Redis can't handle millions of writes with low latency due to CPU and memory limits.

  2. Step 2: Consider partitioning by region

    Partitioning reduces load per cluster, allows parallel writes, and merging asynchronously balances latency and consistency.

  3. Step 3: Distributed SQL and NoSQL drawbacks

    Distributed SQL has high write latency; NoSQL batch ranking delays real-time queries.

  4. Final Answer:

    Option C -> Option C

  5. Quick Check:

    Partitioned Redis clusters with async merge balance scale and latency [check]
Hint: Partition and merge asynchronously for scale and low latency [check]
Common Mistakes:
4. Without the message broker (e.g., Kafka) in a high-throughput chat system, what exactly breaks in the message delivery flow?
medium
A. Messages are sent synchronously causing sender blocking and message loss on receiver failure
B. Alice's send operation blocks until Bob's server responds; if Bob's server crashes, the message is lost with no retry
C. Messages are encrypted incorrectly causing security breaches
D. The system automatically switches to batch mode causing high latency

Solution

  1. Step 1: Role of message broker

    Broker decouples sender and receiver, enabling asynchronous delivery and retries.

  2. Step 2: Consequence of missing broker

    Without it, messages are sent synchronously causing sender blocking; if receiver crashes, messages are lost; encryption (A) unaffected; blocking and loss (C) is exact failure; batch mode (D) not automatic.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Broker removal causes blocking sends and message loss on receiver failure [check]
Hint: No broker means synchronous sends block and lose messages [check]
Common Mistakes:
5. For a multi-CDN strategy targeting maximum global coverage with low latency, which approach best balances cost and performance when selecting CDNs per user request?
medium
A. Route all traffic to the CDN with the largest global footprint only
B. Always route requests to the cheapest CDN regardless of latency
C. Use a weighted routing algorithm combining CDN latency measurements and cost metrics
D. Randomly select a CDN for each request to distribute load evenly

Solution

  1. Step 1: Analyze routing strategies for cost and latency

    Weighted routing that factors both latency and cost optimizes user experience and budget.

  2. Step 2: Eliminate other options

    Routing only by cost (A) ignores latency, hurting performance. Single largest CDN (C) may not cover all regions well. Random selection (D) ignores both cost and latency, causing unpredictable performance.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Weighted routing balances latency and cost for optimal multi-CDN use [check]
Hint: Weighted routing balances latency and cost per request [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