Bird
Raised Fist0

Design Facebook Messenger - Group Chat, Presence, Message Sync

HLDhardInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🏗️
Design Facebook Messenger - Group Chat, Presence, Message Sync
Design a scalable, low-latency group chat system with presence and message synchronization for billions of users
hardCommunication and Messaging SystemsFreq: high
Prerequisites:System Design FundamentalsCAP TheoremDistributed DatabasesMessaging SystemsConsistency Models
⚙️
Functional Requirements
  • Support group chats with up to 250 members per conversation
  • Real-time presence indication (online/offline/typing) for group members
  • Message synchronization across multiple devices per user
  • Message delivery guarantees: at-least-once delivery with ordering within a conversation
  • Support message history retrieval with pagination
  • Support message edits and deletions with eventual consistency
📊
Non-Functional Requirements
  • Support 2 billion daily active users (DAU)
  • Handle peak write throughput of approximately 925K messages per second
  • End-to-end latency under 100ms P99 for message delivery and presence updates
  • System availability of 99.99% (four nines)
  • Data durability with 30-day message retention and geo-replication
❓
Clarifying Questions to Ask
  • What is the maximum group size we need to support?
  • Are messages guaranteed to be delivered in order within a group?
  • How many devices per user should message sync support?
  • What is the expected message size and average messages per user per day?
  • Is presence real-time or eventual consistency acceptable?
  • What is the retention period for messages and presence data?
Out of Scope
✗ Voice and video calling features
✗ End-to-end encryption key management and cryptography
✗ User authentication and authorization
✗ Media (images, videos) storage and delivery
📌
Assumptions
  • 2 billion DAU
  • Average 40 messages per user per day
  • Average message size 100 bytes
  • Average 3 devices per user for message sync
⚡
QPS Calculation
write qps2B × 40 / 86400 ≈ 925,926 messages/sec
peak write qpsAssuming 3× peak factor: 925,926 × 3 ≈ 2.78M messages/sec
read qpsAssuming 5 reads per write (message sync, presence fetch): 925,926 × 5 ≈ 4.63M reads/sec
💾
Storage Estimate
daily storage2B × 40 × 100 bytes = 8 TB/day
retention 30 days8 TB × 30 = 240 TB
with replication 3x240 TB × 3 = 720 TB total storage
🖥️
Server Estimate
message ingestionKafka cluster with 100 brokers, each handling ~30K msg/sec
storage nodesCassandra cluster with 500 nodes, each storing ~1.5 TB data with replication
🏗️
Architecture Diagram
Architecture Diagram
          +-------------+
          |  User Devs  |
          +------+------+
                 |
          +------+-------+
          |  API Gateway |
          +------+-------+
                 |
         +-------+--------+
         |  Load Balancer |
         +-------+--------+
                 |
   +-------------+--------------+
   |                            |
+--v--+                    +----v----+
| Msg |                    | Presence|
| Srv |                    |  Srv    |
+--+--+                    +----+----+
   |                            |
   |                            |
   |                            |
   |                            |
+--v---------------------------v---+
|          Kafka Cluster             |
+--+----------------------------+---+
   |                            |
   |                            |
+--v--+                    +----v----+
|Cassandra|                 | Redis   |
| Cluster |                 | Cluster |
+---------+                 +---------+
🧩
Components
API Gateway
Entry point for client requests, handles authentication, rate limiting, and routing
Why thisEnvoy proxy supports high throughput, low latency, and dynamic routing for 2B DAU
Why notNginx lacks native service discovery and dynamic routing needed at this scale
Message Service
Handles message ingestion, validation, ordering, and publishing to Kafka
Why thisStateless microservice horizontally scalable to handle 2.78M peak msg/sec
Why notMonolithic servers would bottleneck and complicate scaling and deployment
Presence Service
Manages real-time user presence state with sub-second updates
Why thisRedis with TTL and Pub/Sub supports sub-millisecond presence lookups and event propagation
Why notMemcached lacks native TTL event notifications and persistence for presence data
Kafka Cluster
Durable, ordered, partitioned message queue for decoupling ingestion and storage
Why thisKafka supports high throughput, partitioning by conversation_id ensures ordering within groups
Why notRabbitMQ does not scale linearly to millions of partitions and high throughput
Cassandra Cluster
Stores message history and metadata with high write throughput and geo-replication
Why thisCassandra's wide-column model and tunable consistency fit large-scale message storage with 3 replicas
Why notPostgreSQL requires complex manual sharding and cannot sustain 925K writes/sec
Redis Cluster
Caches recent messages and presence data for low-latency reads and sync
Why thisRedis supports fast in-memory lookups with TTL for presence and message sync caching
Why notElasticsearch is optimized for search, not low-latency key-value caching
🔄
Data Flow
1
User Device → API Gateway
Send message or presence update
Client sends message or presence event via persistent connection
2
API Gateway → Message Service / Presence Service
Route request based on type
Message requests go to Message Service; presence updates to Presence Service
3
Message Service → Kafka Cluster
Publish message to Kafka topic partitioned by conversation_id
Ensures ordered, durable message queueing
4
Kafka Cluster → Cassandra Cluster
Consume messages and persist to Cassandra
Asynchronous durable storage with replication
5
Presence Service → Redis Cluster
Update presence state with TTL and publish events
Presence state expires automatically; events notify subscribers
6
Redis Cluster / Cassandra Cluster → User Devices
Serve presence and message sync requests
Clients fetch presence and message updates from cache or storage

Practice

(1/5)
1. A browser needs to resolve a domain name to an IP address but wants to avoid repeated queries to external servers for the same domain within a short time. Which component in the DNS resolution chain primarily handles this optimization?
easy
A. The authoritative DNS server for the domain, which caches recent queries to speed up responses
B. The local DNS resolver (stub resolver) on the user's machine, which caches recent lookups to reduce network calls
C. The root DNS server, which maintains a cache of all domain-to-IP mappings globally
D. The recursive DNS server, which never caches results and always queries authoritative servers

Solution

  1. Step 1: Identify the role of the local DNS resolver

    The local DNS resolver (stub resolver) on the user's machine caches recent DNS lookups to avoid repeated network queries for the same domain within a short time.

  2. Step 2: Eliminate other options

    Authoritative DNS servers provide domain data but do not cache queries for clients. Root servers do not cache all mappings globally and are rarely queried directly. Recursive DNS servers do cache results to improve performance, so The recursive DNS server, which never caches results and always queries authoritative servers is incorrect.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Local resolver caches to reduce network calls [check]
Hint: Local resolver caches recent lookups to reduce queries [check]
Common Mistakes:
2. In a microservices architecture, a client request flows through API Gateway -> Auth Service -> Order Service -> Inventory Service. At step 3, the Order Service calls Inventory Service synchronously. What happens if Inventory Service is slow at step 3?
easy
A. Auth Service caches Inventory Service response to speed up future calls
B. Order Service queues the request asynchronously and immediately returns success to client
C. API Gateway retries the Inventory Service call automatically without client awareness
D. Order Service blocks the client request until Inventory Service responds or times out

Solution

  1. Step 1: Trace synchronous call behavior at step 3

    Order Service calls Inventory Service synchronously, so it waits for response before replying to client.

  2. Step 2: Analyze impact of slow Inventory Service

    Because of synchronous call, client request blocks until Inventory Service responds or times out; no immediate return or retries happen automatically.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Synchronous calls block caller until response or timeout [check]
Hint: Synchronous calls block caller until response or timeout [check]
Common Mistakes:
3. A messaging system must decouple high-throughput message producers from multiple independent consumers subscribing to different topics. Which component best handles this decoupling and ensures message durability?
easy
A. Use a distributed log-based system like Kafka with topic partitions
B. Use a simple in-memory queue on the producer server to buffer messages
C. Use a direct HTTP push from producer to each consumer
D. Use a relational database with polling by consumers

Solution

  1. Step 1: Identify decoupling and durability needs

    In-memory queues (Use a simple in-memory queue on the producer server to buffer messages) lack durability and don't scale across servers. Direct HTTP push (Use a direct HTTP push from producer to each consumer) tightly couples producer and consumers, causing backpressure issues. Polling a relational DB (Use a relational database with polling by consumers) adds latency and load on DB, unsuitable for high throughput.

  2. Step 2: Recognize Kafka's role

    Kafka's distributed log with topic partitions decouples producers and consumers, provides durability, and supports high throughput with consumer groups.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Kafka partitions enable durable, scalable decoupling [check]
Hint: Distributed logs decouple producers and consumers reliably [OK]
Common Mistakes:
4. Without the Expiration Worker component, what exactly breaks in the Pastebin system?
medium
A. Expired snippets remain stored indefinitely, causing storage bloat and stale data served to users
B. Users cannot create new snippets because the storage is locked waiting for expiration cleanup
C. Snippet retrieval latency increases drastically due to missing expiration indexes
D. Analytics data becomes inaccurate because expired snippets are still counted as active

Solution

  1. Step 1: Identify Expiration Worker's role

    It removes expired snippets to free storage and prevent stale data serving.

  2. Step 2: Trace failure impact without Expiration Worker

    Expired snippets accumulate indefinitely, increasing storage and possibly serving stale content.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Without expiration cleanup, storage bloat and stale data occur [check]
Hint: No expiration worker -> storage bloat and stale snippets served [check]
Common Mistakes:
5. You need to implement a live news feed with many clients receiving frequent updates but no client-to-server messages. Which technology is best considering scalability and simplicity?
medium
A. Use WebSockets to maintain persistent connections for all clients to push updates.
B. Use Server-Sent Events to push unidirectional updates efficiently with automatic reconnection.
C. Use Long Polling to simulate server push by clients repeatedly requesting updates.
D. Use HTTP/2 server push to send updates without client requests.

Solution

  1. Step 1: Analyze communication pattern

    Live news feed requires unidirectional server-to-client updates with many clients and no client messages.

  2. Step 2: Evaluate technology trade-offs

    Server-Sent Events efficiently support unidirectional streaming with automatic reconnection and lower overhead than WebSockets. WebSockets add complexity and resource usage for no client-to-server messages. Long Polling is less efficient due to repeated HTTP requests. HTTP/2 server push is not widely supported for this use case.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Server-Sent Events optimize unidirectional streaming with scalability [check]
Hint: Unidirectional + many clients -> Server-Sent Events [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