Bird
Raised Fist0

Design Facebook Messenger - Group Chat, Presence, Message Sync

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

Receives Alice's group chat message over WebSocket

API Gateway authenticates and forwards message to Message Service

Protocol:WebSocket
BeforeAlice's device has a new plaintext group chat message ready to send
AfterMessage received by API Gateway, ready for processing
Message Service

Processes and validates message, then produces event to Kafka

Message Service ensures message format and publishes to Kafka topic

Protocol:Kafka Produce
BeforeMessage Service has received raw message from API Gateway
AfterMessage durably committed to Kafka Cluster for delivery
Kafka Cluster

Stores message event and delivers to Message Service consumer

Kafka partitions by group chat ID to preserve ordering

Protocol:Kafka Consume
BeforeMessage event is stored in Kafka topic partition
AfterMessage Service consumer receives message event for delivery
Message Service

Checks recipient presence in Redis and delivers or queues message

Queries Redis for online status; delivers via WebSocket or stores in Cassandra

Protocol:Redis GET/SET
BeforeMessage Service has message event from Kafka but no recipient presence info
AfterRecipient presence known; message delivered or queued accordingly
Redis Cluster

Stores updated presence info and session state

Presence Service updates Redis with user online/offline status

Protocol:Redis SET
BeforePresence Service has new presence event from user activity
AfterRedis cache reflects current user presence for fast lookup
Cassandra Cluster

Persists message for offline recipients and sync across devices

Message stored durably for retrieval and sync by clients

Protocol:Cassandra Write
BeforeMessage Service has message to persist for offline delivery
AfterMessage durably stored in Cassandra; available for sync and history retrieval
Presence Service

Consumes presence events and updates Redis cache

Keeps user presence state fresh for delivery decisions

Protocol:Redis SET
BeforePresence Service receives user presence change event
AfterPresence cache updated; delivery logic uses fresh presence info
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│  API Gateway  │
└───────┬───────┘
        │ WebSocket
        ▼
┌───────────────┐
│ Message Srv   │
│ (handles chat │
│  logic)       │
└───────┬───────┘
        │ Kafka Produce
        ▼
┌───────────────┐
│ Kafka Cluster │
│ (message bus) │
└───────┬───────┘
        │ Kafka Consume
        ▼
┌───────────────┐
│ Message Srv   │
│ (delivery)    │
└───────┬───────┘
        │ Redis GET/SET
        ▼
┌───────────────┐
│ Redis Cluster │
│ (presence &   │
│  session cache)│
└───────┬───────┘
        │ Cassandra Write
        ▼
┌───────────────┐
│ Cassandra     │
│ Cluster       │
│ (message store│
│  & sync)      │
└───────────────┘
        ▲
        │ Presence Update
┌───────┴───────┐
│ Presence Srv  │
│ (tracks user  │
│  online state)│
└───────────────┘
Design Rationale

This architecture for Facebook Messenger group chat uses a vertical flow starting from the API Gateway, which handles WebSocket connections from clients. The Message Service processes incoming messages and publishes them to a Kafka Cluster, which acts as a durable, ordered event bus. Another Message Service consumer reads from Kafka to deliver messages, consulting Redis Cluster for recipient presence. Redis caches presence and session data for low-latency lookups. Offline messages are persisted in Cassandra Cluster for durable storage and sync across devices. The Presence Service updates Redis with user online/offline state, enabling real-time delivery decisions. This design decouples message ingestion, delivery, presence tracking, and storage, ensuring scalability and responsiveness for group chat and presence features.

Primary Focus

✓

Practice

(1/5)
1. In the request flow, at Step 4 the Delivery Worker checks the message queue's visibility timeout before processing. What happens if the visibility timeout expires before the message is acknowledged?
easy
A. The message is moved to a dead-letter queue without retry
B. The message is deleted immediately to prevent duplicates
C. The message is archived permanently without redelivery
D. The message becomes visible again and can be redelivered to another worker

Solution

  1. Step 1: Understand visibility timeout semantics

    Visibility timeout hides the message during processing; if not acknowledged, it reappears for redelivery.

  2. Step 2: Analyze options

    Immediate deletion (A) risks data loss; archiving without retry (C) prevents recovery; dead-letter queue (D) is for failed retries, not timeout expiry.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Visibility timeout expiry -> message reappears for retry [check]
Hint: Visibility timeout expiry -> message requeued for retry [check]
Common Mistakes:
2. A social media platform must handle 1 million new posts per second and fan-out updates to millions of followers asynchronously. Which component is best suited to decouple the high write throughput from the fan-out delivery process?
easy
A. Use a cache like Redis to store all posts and push updates directly
B. Use a relational database with triggers to notify followers synchronously
C. Use a distributed message queue like Kafka partitioned by user ID
D. Use a polling mechanism where followers fetch updates periodically

Solution

  1. Step 1: Identify the need for decoupling writes and fan-out

    Relational DB triggers (A) cause synchronous blocking and don't scale to 1M writes/sec. Redis (C) is fast but lacks durability and ordering guarantees for fan-out. Polling (D) adds latency and load on clients.

  2. Step 2: Evaluate Kafka for asynchronous, durable, partitioned messaging

    Kafka partitions by user ID to preserve ordering per user and decouples writes from fan-out delivery, handling high throughput efficiently.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Kafka partitions enable scalable, ordered fan-out delivery [check]
Hint: Kafka partitions decouple writes and preserve ordering [check]
Common Mistakes:
3. For a globally distributed collaborative editor with many offline users, which approach better supports eventual consistency and offline edits, and why?
medium
A. Use Operational Transformation (OT) because it requires a central server to order operations
B. Use a relational database with strict locking to serialize all edits globally
C. Use CRDTs because they allow local operations to be merged without coordination and support offline edits
D. Use a message queue with timestamp ordering to ensure global operation order

Solution

  1. Step 1: Compare OT and CRDT for offline and distributed scenarios

    OT typically requires a central server to order and transform operations, making offline support complex.

  2. Step 2: Understand CRDT advantages

    CRDTs are designed for decentralized environments, allowing local operations to be merged eventually without coordination, ideal for offline edits and global distribution.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    CRDTs enable offline edits and eventual consistency without central coordination [check]
Hint: CRDTs merge offline edits without central coordination [OK]
Common Mistakes:
4. Without a rate limiter in place, what exactly happens when a sudden traffic spike occurs on a backend service?
medium
A. The backend service crashes or becomes unresponsive, causing client requests to time out or fail
B. The backend service rejects requests gracefully with error codes indicating overload
C. The backend service automatically scales up instantly to handle the spike
D. The backend service queues all requests, causing increased latency but no failures

Solution

  1. Step 1: Understand backend behavior without rate limiting

    Without rate limiting, traffic spikes overwhelm backend, causing resource exhaustion and crashes or unresponsiveness.

  2. Step 2: Eliminate incorrect failure modes

    Automatic instant scaling (C) is unrealistic; graceful rejection (D) requires rate limiting; queuing all requests (A) leads to resource exhaustion and eventual failure.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Spike without limiter -> backend crash or unresponsiveness [check]
Hint: No limiter -> spike crashes backend, causing timeouts [check]
Common Mistakes:
5. At 10x scale, which component of the Snowflake ID generation system is most likely to become the bottleneck first, and why?
hard
A. The timestamp source, because clock synchronization across machines becomes impossible at scale.
B. The network bandwidth, because ID generation requires frequent coordination between machines.
C. The sequence number, because generating more than its max IDs per millisecond causes blocking delays.
D. The machine ID allocation, because limited machine ID bits cause ID collisions as machines increase.

Solution

  1. Step 1: Analyze timestamp and network constraints

    Timestamp synchronization (A) is challenging but tolerable with NTP; network coordination (D) is minimal as IDs are generated locally.

  2. Step 2: Evaluate sequence number limits

    Sequence number (B) limits per millisecond can cause blocking but can be mitigated by load balancing or sharding.

  3. Step 3: Identify machine ID allocation bottleneck

    Machine ID bits are fixed (e.g., 10 bits), limiting the number of unique machines. At 10x scale, running out of unique machine IDs causes collisions or requires complex reallocation.

  4. Final Answer:

    Option D -> Option D

  5. Quick Check:

    Fixed machine ID bits limit scale -> collisions or reconfiguration needed [check]
Hint: Fixed machine ID bits limit scale before sequence or timestamp issues [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