Design Facebook Messenger

Problem and Scope

Design a messaging service for one-to-one and group conversations. A user may be signed in on several devices, move between reliable and unreliable networks, and expect messages to arrive quickly without losing conversation history. Group chats can range from a few friends to very large communities. The product should support sending, receiving, and catching up after time offline. Clarify the delivery and consistency guarantees you want to provide, then walk through the system.

Focus first on sending, receiving, and recovering conversation history. State the delivery and ordering guarantees users can rely on, then define how those guarantees change for offline devices and larger groups.

Requirements to Clarify

A strong answer should establish scope before choosing components.

Functional requirements:

• Users should be able to start group chats (including one-to-one chats)
• Users should be able to send and receive messages between different users
• Support media attachments (photos, videos, audio)
• Users should be able to access messages after being offline

Non-functional requirements:

• Low latency for message delivery (~500ms)
• Guaranteed message delivery
• Support for billions of users with high throughput
• Minimal server-side message storage (privacy/security concerns)
• Fault tolerance

Scale and Capacity

Use the workload to justify storage, partitioning, caching, and reliability decisions. Clarify or challenge these assumptions rather than treating them as unquestionable facts:

• Billions of users
• Each user sends approximately 100 messages per day
• Messages are typically small (< 1KB) but media attachments can be large
• Total throughput: ~100 billion messages per day
• Storage requirements: ~100 TB per day for messages alone

Architecture Discussion

Walk through the important read and write paths, identify ownership boundaries, and explain how the design behaves when dependencies fail. Cover these areas explicitly:

• Client applications (mobile, web)
• Chat servers to handle websocket connections
• Message persistence layer
• User/chat metadata storage
• Media storage system
• Load balancer and routing system
• Presence indicator system (optional)
• Multi-device synchronization system (optional)
• Maintaining persistent connections for billions of users
• Routing messages between different chat servers
• Ensuring message delivery when recipients are offline
• Handling media attachments efficiently
• Scaling horizontally while maintaining low latency
• Managing client-server synchronization
• Load balancing with stateful connections
• Privacy and data retention policies

Follow-up Questions

Expect the interviewer to test the consequences of your choices. Practise answering these questions with a concrete decision, its benefit, and its cost:

• How would your system handle message delivery across different chat servers?
  • Focus: Assess the candidate's answer to "How would your system handle message delivery across different chat servers" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
• What happens if a recipient is offline when a message is sent?
  • Focus: Assess the candidate's answer to "What happens if a recipient is offline when a message is sent" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
• How would you optimize the handling of media attachments?
  • Focus: Assess the candidate's answer to "How would you optimize the handling of media attachments" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
• How would your system scale as the number of users grows?
  • Focus: Assess the candidate's answer to "How would your system scale as the number of users grows" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
• What trade-offs did you consider when designing your data model?
  • Focus: Assess the candidate's answer to "What trade-offs did you consider when designing your data model" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
• How would your system handle fault tolerance?
  • Focus: Assess the candidate's answer to "How would your system handle fault tolerance" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
• How would you implement the presence indicator feature?
  • Focus: Assess the candidate's answer to "How would you implement the presence indicator feature" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.

Evaluation Rubric

MockMe evaluates the answer across the following dimensions. A complete answer should connect claims to requirements and explain consequential trade-offs.

• Requirements and scope (15%): Clarifies and prioritizes the required behavior for Users should be able to start group chats (including one-to-one chats); Users should be able to send and receive messages between different users; Support media attachments (photos, videos, audio). Establishes the constraints that materially affect Design Facebook Messenger, including Low latency for message delivery (~500ms); Guaranteed message delivery. Strong evidence includes Separates the critical path from secondary features and resolves ambiguous requirements before choosing components.
• Architecture and interfaces (20%): Presents coherent ownership boundaries and end-to-end flows covering Client applications (mobile, web); Chat servers to handle websocket connections; Message persistence layer; User/chat metadata storage. Strong evidence includes Defines interfaces and traces important success, retry, and failure paths across the proposed components.
• Data and scaling (25%): Uses workload assumptions such as Billions of users; Each user sends approximately 100 messages per day to justify capacity and partitioning decisions. Explains the data, state, or model strategy for User/chat metadata storage; Media storage system; Privacy and data retention policies. Strong evidence includes Quantifies a dominant workload, identifies the first bottleneck, and explains how the design evolves as that workload grows.
• Reliability, correctness, and safety (20%): Explains concrete failure behavior, recovery, and operational safeguards for Privacy and data retention policies; Minimal server-side message storage (privacy/security concerns). Strong evidence includes States the required correctness or consistency boundary and covers retries, partial failure, observability, and safe degradation.
• Communication and trade-offs (20%): Drives a structured discussion and compares consequential alternatives for Managing client-server synchronization; Load balancing with stateful connections; Privacy and data retention policies. Strong evidence includes Makes assumptions explicit, answers the question asked, and explains both the benefit and cost of major decisions.