Design Facebook Messenger

Functional

At its core, Messenger is a real-time chat application. Here are the key capabilities:

• One-on-one messaging: A user can send and receive text messages with another user.
• Group chat: A user can create a group, add/remove members, and send messages to all group members.
• Message persistence: Messages are stored for 1 year.
• Media sharing: Users can share images and videos (stretch goal if time allows).

Traffic

• 500M DAU, average 10 minutes of chat activity per day
• At peak, ~20% of users (100M) are chatting simultaneously

Storage

The Key Decision: How Do Client and Server Exchange Messages?

This is the most important API decision, and interviewers expect you to reason through it:

Option 1: Client polls server: The client asks "any new messages?" every few seconds. At 100M concurrent users polling every 2 seconds, that's 50M requests/second, most returning empty responses. Wasteful.

Analyzing the Data

Before picking a database, let's understand what we're storing:

Text messages: 5-8PB over 10 years (accounting for user growth). Each record is small, but the aggregate footprint is enormous and the write stream is continuous. Messages are mostly immutable, once a message is sent, it rarely changes. The access pattern is: write once, read by group members, ordered by timestamp.

Let's walk through each component and why it's there:

Rate Limiter: Sits at the edge, preventing DoS attacks and abusive clients (e.g., a bot sending thousands of messages per second). Without this, a single bad actor could overwhelm the entire system.

Sending a Message

Let's trace what happens when User A sends "Hello!" in a group chat:

Database Sharding

Cassandra needs a sharding strategy for the messages table. Three options to consider:

Server-Side vs. Client-Side Timestamps

Message ordering depends on timestamps, so who assigns them matters. We choose server-side timestamps for two reasons:

1. Server clocks are synchronized. We control our servers and can use NTP or Google's TrueTime (atomic clock-based) to keep them within microseconds of each other. Client clocks? We have zero control; they can be minutes or hours wrong.
2. No clock skew across devices. If User A is on a phone with the wrong time and User B is on a laptop, their client timestamps would place messages in nonsensical order. Server timestamps guarantee a single source of truth.

Client Network Failure

Network drops are the most common failure in a chat app. Here's how we handle both directions:

Sending side (client cannot reach server):

End-to-End Encryption

Currently, Chat Service can read message content (needed for content moderation). End-to-end encryption (E2EE) would encrypt messages on the sender's device and decrypt only on the recipient's. The server would store ciphertext it cannot read. Challenge: group chats require key distribution to all members, and key rotation when members are removed.

Content Moderation