Loading…

The decisions that matter

Use gateways for long-lived device connections.Messages are pushed within the latency target without billions of empty polls.
Persist ciphertext before the sender sees the tick.A server crash after the tick cannot erase accepted messages.
Assign a per-conversation position from one owner.Every device renders the same order and can fetch missing positions.
Track progress per device.A phone and laptop can reconnect independently without stealing messages from each other.
Encrypt for devices, not for accounts.The service stores public keys and ciphertext envelopes, while private keys stay on devices.

Architecture diagramThe final design at a glance

The whole design: gateways hold device connections, one conversation owner orders each chat, a replicated store keeps ciphertext envelopes until devices acknowledge them, and delivery workers push or wake devices. Dashed lines are asynchronous.

Diagram as text

Components: Alice’s devices (Client); Gateway A (API gateway); Chat service (Service); Conversation owner (Service); Message log and device positions (NoSQL DB); Public-key directory (Auth); Device to gateway registry (Cache); Delivery workers (Worker); Recipient gateways (API gateway); Push notification (Notifications); Bob’s devices (Client). Connections: Alice’s devices → Gateway A (send ciphertext); Gateway A → Chat service; Chat service → Conversation owner (next seq); Conversation owner → Message log and device positions (save, then tick); Chat service → Device to gateway registry (where are devices?); Public-key directory → Alice’s devices (public keys), asynchronous; Conversation owner → Delivery workers (pending envelopes), asynchronous; Delivery workers → Recipient gateways (push online); Recipient gateways → Bob’s devices (deliver); Message log and device positions → Push notification (wake offline), asynchronous; Push notification → Bob’s devices (connect later), asynchronous.

Understanding the problem

This is a global messenger design, not a description of WhatsApp’s production system. The user action is simple: a device sends a text, photo or file into a one-to-one chat or group, and every device that belongs in the chat should see it in the same order. The hard parts are the gaps between that sentence and a real network: hundreds of millions of devices are connected at once, phones disappear without closing connections, people use several devices, groups multiply delivery work, and the service must route messages it cannot read.

Start by repeating the brief: one-to-one and group messaging, linked devices, media, receipts, presence and end-to-end encryption. Then draw a line around what the interview can solve in time: the messaging service from Send to delivery on every device.

Functional requirements

CoreSend and receive messages in 1:1 chats and in groups of up to 1,000 members.
CoreA message to someone whose phone is off reaches them when they come back, even days later.
CoreEach message shows when it was sent, delivered and read.
CoreSend photos, videos and files of up to 100 MB.
CoreUse one account on a phone and up to 4 linked devices (desktop, web, tablet), all in sync.
CoreSee whether a contact is online, or when they were last seen.
Below the lineTyping indicators.
Below the lineSearching old messages.
Below the lineEditing and deleting sent messages.
Below the lineBacking up chats.
Below the lineVoice and video calls.They use different media paths, call setup and quality controls. Mention that they are separate.
Below the lineStories, payments and address-book discovery.They are product surfaces around messaging, not the send-to-deliver path.
Below the lineFull-text search of old messages.End-to-end encryption pushes search onto devices, and history lives on devices.

Non-functional requirements

DurabilityA message the service has accepted is never lost while it waits for a device (up to 30 days), and it shows exactly once on each device.
ConsistencyEveryone in a chat sees its messages in the same order, on every device.
LatencyA message to someone who is online arrives within about 500 ms at the 99th percentile, worldwide.
SecurityChats are end-to-end encrypted: only the devices in a chat can read its messages, not the service.
AvailabilitySending and receiving stay available (99.99%), even when a whole region is down.

Scale

From the briefNumbers here are given in the practice brief.

ScaleAbout 2 billion users; about 500 million devices connected at the busiest moment.
ScaleAbout 100 billion messages a day.
ScaleMost chats are 1:1 and most groups have under 20 members, but a busy 1,000-member group can get about 50 messages a second.
ScaleAbout 5% of messages carry a photo, video or file, about 200 KB on average.
ScaleUsers on every continent; the service runs in several regions.

Out of scope

Out of scopeStatus updates and stories.
Out of scopePayments.
Out of scopeFinding contacts from the address book.
Out of scopeSpam and abuse detection.

Check yourself

Why is "chat history lives on devices" important to the architecture?
Show answerHide answer
It keeps the server from becoming a readable history store. The server keeps ciphertext envelopes while devices still need them, then devices own long-term history and sync new devices end to end.

The numbers that shape the design

Illustrative exampleNumbers here are illustrative: round figures to reason with, not measurements.

Use the brief’s scale to find the bottlenecks, not to produce false precision. The sends are high, but the design is shaped more by open connections, copies to devices, group fan-out and media bytes.

Back of the envelope for the global messenger

Quantity	Value	What it tells us
Messages	About 100B a day, about 1.2M a second on average	The write path must be horizontally partitioned; a single relational primary is not the message store.
Deliveries	Illustrative several million a second after copies	One send becomes copies to recipient devices, sender linked devices and group members.
Open connections	About 500M devices at peak	Gateway capacity is about long-lived connections, memory and heartbeats, not request rate only.
Groups	Up to 1,000 members; a busy one can reach about 50 messages a second	Large groups need a different storage and delivery mode from small groups.
Media	About 5% of messages, around 200 KB on average, with files up to 100 MB	Media belongs in object storage, encrypted on the device and referenced from messages.

What the numbers tell you

Gateway servers hold connections and heartbeats for hundreds of millions of devices.
The message store is write-heavy and reads one conversation from a position, so partition by conversation id.
Delivery capacity is larger than send capacity because one send creates several device deliveries.
Media and group fan-out need separate paths so text delivery stays fast.

Architecture diagramWhat the scale changes

Read:Learn: Numbers and capacity estimation Learn: Queues, delivery semantics and backpressure

Try it: The numbers that shape the designGuided practice · Chat, Global messenger · Senior

Check yourself

Which number sizes the gateway fleet?
Show answerHide answer
The peak connected devices. Requests per second matter, but gateways mostly hold long-lived connections, heartbeat state and send buffers.

Core entities

Model the reads first. A chat screen asks for one conversation after a position; a reconnecting device asks for what it missed; a sender asks which devices belong to each member. Keep message bodies as opaque ciphertext envelopes. Plaintext is not a server field.

The records that matter

Record	Key fields	Why it exists
Conversation	`id`, type, created_by, home_region	The chat whose order is managed together.
Conversation member	`conversation_id`, `user_id`, role, joined_at	Who should receive group or one-to-one messages.
Device	`user_id`, `device_id`, public identity key, push token	Every phone, laptop or tablet is a separate encryption and delivery target.
Message envelope	`conversation_id`, `seq`, client_msg_id, sender_device_id, ciphertext, media_ref?	The ordered item devices read. The body is opaque to the service.
Device position	`device_id`, `conversation_id`, delivered_seq, read_seq	Where one device has got in one chat.
Presence mark	`user_id`, expires_at, last_seen_at	A short-lived online signal from live connections.

Storage choices by access pattern

Data	Store shape	Partition key
Message envelopes	Wide-column or key-value store with ordered range reads	Conversation id, with sequence as sort key
Device positions	Wide-column or key-value store	Device id, then conversation id
Connection registry	Fast in-memory store with expiry	Device id
Media blobs	Object storage and CDN	Object id
Public keys	Key directory with auditable device records	User id and device id

Architecture diagramThe data model follows the reads

Read:Learn: Data model design Learn: Storage choice justification Learn: Apache Cassandra Learn: Redis

Try it: Messages, chats and devicesGuided practice · Chat, Global messenger · Senior

Check yourself

Why is splitting messages by sender a bad fit?
Show answerHide answer
A conversation read would scatter across every sender’s partition. Split by conversation so a device reads one ordered range from its position.

The API

Most chat actions are frames on one authenticated persistent connection. The exception is media: the device gets an upload target, encrypts the file locally and uploads directly to object storage. Every send is safe to retry because the client chooses the message id before the first attempt and reuses it.

Protocol frames and calls

Frame or call	Request	Response	Rule
`WS connect`	Device token, last known positions	Frames both ways	The gateway refreshes device routing while heartbeats arrive.
`send` frame	`conversation_id`, `client_msg_id`, ciphertext, media_ref?	`accepted {client_msg_id, seq}`	A repeat of the same client id returns the original result.
`deliver` frame	Server to device	`conversation_id`, `seq`, `client_msg_id`, ciphertext	The device ignores a message id it has already stored.
`receipt` frame	`conversation_id`, delivered or read, `up_to_seq`	Ack	Store a mark per conversation, not one row per message per member.
`sync` frame	Device positions by conversation	Paged messages after each position	Used after reconnect and for slow devices catching up.
`POST /media`	Size and encrypted-file hash	Signed upload URL and media_ref	Reject too large; upload encrypted bytes outside the chat connection.

Architecture diagramOne connection for small frames, one media path for large files

Read:Learn: API contract design Learn: Idempotency and retries Learn: Large file upload & blob handling Learn: S3 / Blob Storage

Try it: What travels on the connectionGuided practice · Chat, Global messenger · Senior

Check yourself

The app resends because it lost the response to send. What stops a duplicate?
Show answerHide answer
The phone uses the same client message id. The service stores (conversation_id, client_msg_id) once and returns the original sequence on a repeat; devices also drop repeated ids.

High-level design

Now build the path in delivery order: connect devices and route to them, accept a send safely, then keep devices, media and receipts in sync. The deep dives harden the order, durability, devices, encryption, groups and regions.

Keep devices connected and route to them

Every device holds one authenticated WebSocket, MQTT or custom TCP connection to a gateway. Gateways are connection holders, not chat owners. On connect they write (device_id -> gateway_id) into a registry with a short expiry, refreshed by heartbeats. To deliver an online message, the chat service stores it, looks up every target device and hands the envelope to the gateway that holds that device.

Alice’s phone sends a frame to Gateway A.
Gateway A passes it to the chat service.
The chat service stores the envelope and asks the registry where Bob’s devices are connected.
It hands the envelope to Gateway B, which pushes it down Bob’s open connection.
If a device has no route, the service keeps the envelope and sends only a wake-up notification.

Architecture diagramOnline delivery through the right gateway

The sender and recipient do not need to share a server: the chat service looks up recipient devices and hands each envelope to the gateway that holds that device.

Diagram as text

Components: Alice’s phone (Client); Gateway A (API gateway); Chat service (Service); Message store (NoSQL DB); Connection registry (Cache); Gateway B (API gateway); Bob’s phone (Client). Connections: Alice’s phone → Gateway A (open connection); Gateway A → Chat service (send); Chat service → Message store (save first); Chat service → Connection registry (lookup devices); Chat service → Gateway B (deliver copy); Gateway B → Bob’s phone (push over open line).

Read:Learn: Networking fundamentals Learn: Real-time delivery architecture Learn: Protocols and real-time transports

Try it: A message, end to endGuided practice · Chat, Global messenger · Senior

Check yourself

Why not have phones poll every few seconds?
Show answerHide answer
At this scale most polls are empty, and polling misses the half-second target. A persistent connection lets the server push when it has something.

Accept, store and wake offline devices

A send becomes durable before the sender sees the tick. The conversation owner assigns the next position, the message store replicates the ciphertext envelope, and only then does the service answer the sender. For an offline device, the envelope stays pending and the push notification is only a nudge to connect.

The send reaches the chat service with a stable client message id.
The conversation owner assigns the next position for that chat.
The envelope is written to replicated storage and device delivery state says who still needs it.
The sender gets the sent tick after that write.
Offline devices get a push notification; when they connect, they sync from their positions and acknowledge.

Architecture diagramWrite first, tick second, forget last

Sync linked devices, media and receipts

Each phone, laptop and tablet owns its delivery position. A laptop reading a message does not mark the phone as delivered, although read state can sync to the user’s other devices as a receipt. Media uses a separate encrypted upload path, and receipts use compact read-up-to marks instead of one row per message per member.

Every device acknowledges delivered positions for itself.
Read receipts travel as small frames and update a per-conversation mark.
A reconnecting device sends positions and receives pages after those positions.
Media bytes are encrypted on the device and uploaded outside the chat connection.

Architecture diagramEach device has its own progress

Design WhatsApp

The answer in two minutes

Also asked as

What interviewers look for

The decisions that matter

Understanding the problem

Functional requirements

Non-functional requirements

Scale

Out of scope

The numbers that shape the design

Core entities

The API

High-level design

Keep devices connected and route to them

Accept, store and wake offline devices

Sync linked devices, media and receipts

Sign in with Google to read the rest

Practise this

The answer in two minutes

Also asked as

What interviewers look for

The decisions that matter

01Understanding the problem

Functional requirements

Non-functional requirements

Scale

Out of scope

02The numbers that shape the design

03Core entities

04The API

05High-level design

Keep devices connected and route to them

Accept, store and wake offline devices

Sync linked devices, media and receipts

Sign in with Google to read the rest

12Practise this

Understanding the problem

The numbers that shape the design

Core entities

The API

High-level design

Practise this