What is Interview Forge?

Interview Forge helps you practice mock interviews, follow study plans, track career goals, review learning analytics, and prepare across 36 pages.

Design WhatsApp (Chat Messaging) at Amazon — System Design Interview Guide

The problem at Amazon

Functional: 1:1 and group chat, send text/media, offline delivery, read receipts, last-seen, typing indicators.
Non-functional: low-latency delivery, high availability, messages must not be lost, end-to-end encrypted (E2EE).
Scale: ~2B users, ~100B messages/day, mostly small groups (<=256).
Consistency: per-conversation ordering is required; global ordering across conversations is not. Delivery is at-least-once with client dedup (effectively exactly-once).

Out of scope (covered in detail below)

Voice/video calls, status/stories, the E2EE key-exchange protocol, backups, and media (photos/video) — deferred and discussed in the dedicated section.

At Amazon, this problem is framed around customer-obsessed, data-driven, bar-raising. Expect Amazon-specific scale numbers and a focus on production readiness and the company's engineering bar.

Capacity estimation

Resource	Estimate	Notes
Messages/day	~100B	Mostly small payloads
Concurrent connections	~tens of millions	One WebSocket per active client
Message store	~petabytes	Retention policy matters
Presence updates	~millions/s	Heartbeats + state changes

Architecture overview

Connection + delivery

+--------+  WebSocket  +------------------+  publish  +---------+
| Client |<----------->| Connection Svc   |---------->| Kafka   |
+--------+             | (holds sockets)  |           +---------+
                       +------------------+                |
                            ^      |                      v
                            |      v               +---------------+
              +-------------+  +-----------+        | Message Store |
              | Presence    |  | Route map |        | (per conv)    |
              | (Redis TTL) |  | (Redis)   |        +---------------+
              +-------------+  +-----------+

Connection servers hold sockets; a queue decouples send from deliver; the store is the source of truth.

Step-by-step request flow

A client opens a persistent WebSocket to a connection server; the route map records user -> connection server.
Sender sends a message; the connection server persists it to the message store first, then publishes to Kafka.
Consumers look up each recipient's connection server via the route map and push the message over their socket.
Offline recipients: the message stays in the store with a delivery status; on reconnect, the client pulls undelivered messages.
Read receipts and last-seen are presence/status updates, not chat messages — handle them on a lighter path.

Unlock the full guide

Premium members get every DSA, system design, company and role interview guide — plus AI practice, mock interviews, and analytics.

Unlock with Premium