System 12.10 — WhatsApp (Chat at Scale)
In one line
Chat system with the billion-user add-ons: media messages, end-to-end encryption, delivery receipts.
Think of it like this
The chat system above, but running at the scale of 2 billion people, which forces hard choices about how messages are stored, delivered, and kept private (end-to-end encryption).
Key ideas
- 01
Reuse the chat design 12.9 and add the three systems that make it 'WhatsApp': media, encryption, receipts.
- 02
Media: thumbnail + async upload to object store, message carries media_id + hash; client resolves URI via signed URL.
- 03
E2E encryption: message payloads encrypted client-side; server stores ciphertext & metadata only — invisible to the server.
- 04
Receipts: sent / delivered / read triple events — a receipt update event per message (throttle read receipts in groups).
- 05
Groups: fan-out to group members via per-user queues or a group-shared stream with per-member watermark — pick the second at scale.
- 06
Scale: 100s of billions of messages/day — write-heavy; per-conversation partition at planet scale; TTLs purge old messages server-side.
- 07
Throughput math: ~200B msgs/day ≈ 2.3M msg/s avg — that's why partitions + batching + UDP-ish transports are the norm.
- 08
Interview: start from chat (12.9) and layer media → encryption → receipts in order of cost.
Code & diagrams
Same skeleton as Chat System, stretched to billions of users — the diagram doesn't change, the numbers do.
Explain without notes
For a 100k-member group, why is a per-member fan-out queue worse than a shared log with per-member cursors?
Practice
Layer the 'sent/delivered/read' triple onto the chat flow and throttle it for groups.
Trade-offs
- ↔
E2E encryption prevents server-side features (search, spam AI) — the classic product/security trade.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I can present WhatsApp = chat + media + E2E + receipts with the scale math.