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
45 min · senior
senior

You are designing Facebook Messenger for a startup with 50 million daily active users (DAU). The system must support group chats with up to 250 members, real-time presence indicators, and message synchronization across multiple devices. Messages must be end-to-end encrypted. The system should guarantee offline message delivery and maintain a P99 latency under 200ms for message send and receive operations.

Constraints
  • End-to-end encryption for all messages and presence data
  • Offline message delivery with guaranteed eventual consistency
  • Support group chats with up to 250 members
  • P99 latency for message send/receive under 200ms
  • Presence updates must reflect user online/offline status within 30 seconds
  • Support multi-device message synchronization with read receipts
📋
Guided Steps
1/5
Step 1
Message Storage and Partitioning
How would you store and partition messages to support group chats with efficient retrieval and synchronization?
💡 Hint
Consider a storage system optimized for high write throughput and range queries by conversation ID.
Key Decision
Use Apache Cassandra with partition_key=conversation_id to ensure all messages in a group chat are stored on the same node, enabling efficient range scans for cursor-based sync and linear write scalability.
Interviewer Expectation
Mid-level: Names Cassandra for message storage. Senior: Explains why conversation_id is the partition key to maintain message order and avoid cross-node queries, rejecting sender_id as partition key due to out-of-order delivery and inefficient sync.
⚠️Common Wrong Answer
Using a relational database with sender_id as partition key causes cross-shard queries and poor write scalability, leading to high latency and sync failures.
Step 2
Message Delivery and Ordering
How will you ensure ordered, reliable message delivery to all group members, including offline users?
💡 Hint
Think about a distributed messaging system that supports partitioning by conversation and durable storage for offline delivery.
Key Decision
Use Apache Kafka with conversation_id as the partition key to guarantee ordered message delivery per group, combined with durable storage for offline delivery and replay on reconnect.
Interviewer Expectation
Mid-level: Mentions Kafka for message queueing. Senior: Explains Kafka partitioning by conversation_id ensures ordering and co-locates messages for efficient consumption; rejects RabbitMQ due to limited partitioning and throughput at 50M DAU scale.
⚠️Common Wrong Answer
Using RabbitMQ or a single queue leads to message reordering and bottlenecks under high concurrency, causing inconsistent group chat state.
Step 3
Presence System Design
How would you design the presence system to reflect user online/offline status with low latency and scalability?
💡 Hint
Consider an in-memory store with TTL and heartbeat mechanisms to track presence efficiently.
Key Decision
Use Redis with key=user_id and TTL updated every 30 seconds via client heartbeats; presence expires on TTL expiry indicating offline status, enabling fast reads and writes at scale.
Interviewer Expectation
Mid-level: Suggests Redis for presence. Senior: Explains TTL-based expiry with heartbeats to avoid stale presence, rejects polling due to excessive load and latency at 50M DAU.
⚠️Common Wrong Answer
HTTP polling for presence causes 50M reconnects per minute, overwhelming backend and increasing latency beyond 200ms P99.
Step 4
Message Synchronization Across Devices
How will you synchronize messages and read receipts across multiple devices for the same user?
💡 Hint
Think about cursor-based sync using message offsets and a scalable storage backend supporting range queries.
Key Decision
Implement cursor-based sync using Cassandra with conversation_id partitioning and message sequence numbers; clients request messages after last seen offset to efficiently sync new messages and read receipts.
Interviewer Expectation
Mid-level: Describes sync with timestamps. Senior: Explains cursor-based sync with sequence numbers for idempotent, ordered delivery and rejects timestamp-based sync due to clock skew and inconsistent ordering.
⚠️Common Wrong Answer
Timestamp-based sync leads to missing or duplicate messages due to clock skew, causing inconsistent client state.
Step 5
End-to-End Encryption Handling
How will you handle end-to-end encryption for messages and presence data while maintaining system scalability?
💡 Hint
Consider client-side encryption with server-side opaque storage and metadata handling for routing.
Key Decision
Clients encrypt messages and presence data end-to-end; servers store encrypted blobs in Cassandra and Kafka without decrypting, using metadata for routing and delivery only.
Interviewer Expectation
Mid-level: Mentions encryption at rest. Senior: Explains client-side encryption ensures zero trust on server, rejects server-side encryption due to privacy risks and key management complexity at scale.
⚠️Common Wrong Answer
Server-side encryption exposes plaintext to backend, violating privacy and increasing attack surface.
🔌
API Design Challenge
Sketch 3 core API endpoints for Facebook Messenger group chat: sending a message, syncing messages across devices, and updating presence status.
Hints
  • How does the client send a message securely and receive acknowledgement?
  • How does the client efficiently sync messages after reconnect or on a new device?
  • How does the client update and query presence status with low latency?
📊
Scoring Rubric
▼ Show
Must Have - 60%
  • Use of Cassandra with conversation_id partition key for message storage
  • Kafka partitioning by conversation_id for ordered message delivery
  • Redis TTL presence with heartbeat for scalable presence tracking
  • Cursor-based sync with sequence numbers for multi-device message sync
Good to Have - 30%
  • Client-side end-to-end encryption with opaque server storage
  • Durable Kafka storage for offline message delivery
  • Reject HTTP polling and timestamp-based sync with clear reasoning
Bonus - 10%
  • Detailed API design sketch for send, sync, and presence endpoints
  • Explanation of failure modes for common anti-patterns
Anti-patterns to Avoid
HTTP polling for presence causes 50M reconnects per minute just to check for messages - collapses under load and increases latency beyond 200ms P99
Using timestamp-based sync leads to missing or duplicate messages due to clock skew, causing inconsistent client state
Using RabbitMQ for message delivery causes bottlenecks and message reordering at 50M DAU scale due to limited partitioning
Using relational databases with sender_id as partition key causes cross-shard queries and poor write scalability, leading to high latency and sync failures
✅
Model Answer
▼ Reveal

The system uses Apache Cassandra with conversation_id as partition key for scalable message storage and efficient range queries. Apache Kafka partitions messages by conversation_id to guarantee ordered delivery and durable offline storage. Redis tracks presence with TTL and 30-second heartbeats for low latency and scalability. Message synchronization uses cursor-based sync with sequence numbers to ensure idempotent multi-device sync. End-to-end encryption is handled client-side, with servers storing opaque encrypted blobs to preserve privacy.

Key Decisions
  • Use Cassandra with partition_key=conversation_id to store messages ensuring linear scalability and efficient range queries
  • Use Kafka with conversation_id partitioning to guarantee ordered message delivery and durable offline storage
  • Use Redis with TTL and client heartbeats every 30 seconds to track presence status with low latency
  • Implement cursor-based sync using sequence numbers to avoid clock skew issues and ensure idempotent multi-device synchronization
  • Perform client-side end-to-end encryption so servers only handle encrypted blobs, preserving user privacy and simplifying key management
  • Cassandra with partition_key=conversation_id for linear scalable writes and efficient range queries for message sync
  • Kafka with conversation_id as partition key to guarantee ordered message delivery per group chat partition
  • Redis with TTL-based presence tracking and 30-second heartbeat to reflect online/offline status with low latency
  • Cursor-based message synchronization using sequence numbers stored in Cassandra for idempotent multi-device sync
  • Client-side end-to-end encryption ensuring servers only handle opaque encrypted blobs, preserving user privacy
  • Use of durable Kafka storage for offline message delivery and replay on client reconnect
  • Reject HTTP polling for presence due to excessive load and latency at 50M DAU scale
  • Reject timestamp-based sync due to clock skew causing inconsistent message ordering
  • Reject RabbitMQ for message delivery due to limited partitioning and throughput at scale
  • Reject relational databases for message storage due to poor write scalability and cross-shard queries

Practice

(1/5)
1. In a file storage system, at step 3 the client requests a file write. What happens inside the metadata server at this step?
easy
A. The metadata server sends the file data to object storage for persistence.
B. The metadata server writes the file data blocks directly to disk.
C. The metadata server updates the file's inode and directory entries to reflect the new write.
D. The metadata server caches the entire file in memory without updating disk metadata.

Solution

  1. Step 1: Understand metadata server role in file write

    The metadata server manages file metadata like inodes and directory entries, not the actual data blocks.

  2. Step 2: Trace what happens at step 3

    On a write request, the metadata server updates the inode and directory metadata to reflect changes; data blocks are handled separately by storage nodes.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Metadata server updates inode, not data blocks [check]
Hint: Metadata server updates metadata, not file data blocks [check]
Common Mistakes:
2. A deployment system must ensure zero downtime during releases by switching traffic instantly between two identical environments. Which deployment strategy best fits this requirement?
easy
A. Rolling deployment updating servers one by one
B. Canary deployment with gradual traffic shifting to new version
C. Feature flags toggling new features on the same environment
D. Blue-Green deployment with instant switch of load balancer target

Solution

  1. Step 1: Identify zero downtime requirement

    Blue-Green deployment uses two identical environments and switches traffic instantly, ensuring zero downtime.

  2. Step 2: Eliminate other options

    Canary is gradual, not instant; Feature flags don't switch entire environments; Rolling updates cause partial downtime.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Blue-Green switches environments instantly for zero downtime [check]
Hint: Instant switch between identical environments is Blue-Green [OK]
Common Mistakes:
3. In a system generating KSUIDs, at step 4 the ID generator component appends a random payload after the timestamp. What is the state of the generated ID at this step?
easy
A. The ID is a UUIDv4 embedded inside the KSUID format
B. The ID is fully deterministic and only contains the timestamp
C. The ID contains a timestamp prefix followed by a cryptographically secure random payload
D. The ID is a sequential number incremented per node

Solution

  1. Step 1: Understand KSUID structure at step 4

    KSUIDs combine a 4-byte timestamp prefix with a 16-byte random payload to ensure uniqueness and sortability.

  2. Step 2: Eliminate incorrect states

    Deterministic timestamp only (A) lacks uniqueness; UUIDv4 (C) is unrelated; sequential number (D) is not part of KSUID design.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    KSUID = timestamp + random payload for uniqueness and sortability [check]
Hint: KSUID = timestamp prefix + random payload [check]
Common Mistakes:
4. If the API gateway loses the logic to parse the X-API-Version header, what is the exact failure observed by clients using header-based versioning?
medium
A. Clients' requests are routed to the latest version regardless of header, breaking older clients
B. Clients get 404 Not Found errors because the gateway cannot route requests
C. Clients receive responses from the default version, causing silent compatibility issues
D. Clients experience increased latency as the gateway retries version parsing repeatedly

Solution

  1. Step 1: Understand gateway header parsing role

    The gateway uses X-API-Version header to route requests; losing parsing logic means it cannot determine version.

  2. Step 2: Trace failure consequences

    Without parsing, the gateway may retry or fallback inefficiently, causing increased latency rather than immediate errors or silent fallback.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Missing header parsing causes retries and latency spikes [check]
Hint: Lost header parsing -> gateway retries, causing latency [check]
Common Mistakes:
5. Without the Distributed Counter service, what exactly breaks in the API rate limiter system?
medium
A. Edge caches reject all requests since they cannot verify counts locally
B. Rate limits cannot be enforced globally, causing unlimited requests to pass through
C. Clients receive delayed error responses but limits are still enforced eventually
D. The system falls back to client-side enforcement, which is fully reliable

Solution

  1. Step 1: Understand Distributed Counter role

    It provides authoritative counts for enforcement and syncs edge caches.

  2. Step 2: Trace failure without it

    Edge caches rely on counters to verify limits; without counters, they reject all requests to avoid breaches. Global enforcement (B) fails but not silently; client-side fallback (D) is unreliable; delayed errors (A) do not occur.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Edge caches reject all requests without Distributed Counter [check]
Hint: No counters -> edge caches reject all requests to stay safe [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