System design-interview: Ontwerp WhatsApp
"Ontwerp WhatsApp" test realtime aflevering op enorme schaal, duurzame berichtopslag, aanwezigheid (online/laatst gezien), en het verbindingsbeheerprobleem van honderden miljoenen apparaten actief houden. Zoals altijd wil de interviewer je redenering en je trade-offs zien, geen kopie van het echte systeem.
Werk het methodisch uit: verhelder de vereisten, schat de schaal, ontwerp het verbindings- en afleverpad, bepaal hoe berichten worden opgeslagen, en behandel dan groepschat en de lastige randgevallen zoals offline aflevering en volgorde. De onderstaande gids volgt dat pad.
1. Vereisten verhelderen
Leg eerst de scope vast. De kern is één-op-één messaging met betrouwbare aflevering; verhelder of groepschat, media en end-to-end-encryptie binnen de scope van deze ronde vallen.
- Functioneel: berichten verzenden/ontvangen, afleverings- en leesbevestigingen, online aanwezigheid, groepschat, offline aflevering wanneer een ontvanger niet verbonden is.
- Niet-functioneel: lage latentie, hoge beschikbaarheid, duurzaamheid (geen verloren berichten), volgorde binnen een gesprek.
- Te verhelderen: E2E-encryptie en mediaverwerking — benoem ze en bepaal dan expliciet of ze binnen de scope vallen.
2. Schaal inschatten
Leg de cijfers vast die het ontwerp sturen. Neem ~2 miljard gebruikers en tientallen miljarden berichten per dag aan; dat is honderdduizenden berichten per seconde op het hoogtepunt, en honderden miljoenen gelijktijdig verbonden apparaten — verbindingsbeheer wordt een probleem van de eerste orde.
3. Verbindings- en afleverpad
Messaging heeft een persistente verbinding nodig, geen request/response-polling. Apparaten houden een open WebSocket naar een gatewayserver. Een centrale component moet weten welke gateway de verbinding van elke gebruiker momenteel vasthoudt, zodat een bericht naar de juiste server kan worden gerouteerd.
- WebSocket-gateway: houdt actieve apparaatverbindingen in stand, behandelt verzenden/ontvangen.
- Sessie-/aanwezigheidsregister: koppelt gebruiker aan huidige gatewayserver (bijv. in Redis), bijgewerkt bij verbinden/verbreken.
- Berichtroutering: de gateway van de afzender zoekt de gateway van de ontvanger op en stuurt door; als deze offline is, wordt het bericht in de wachtrij geplaatst.
4. Berichtopslag en offline aflevering
Berichten moeten een niet-verbonden ontvanger overleven. Sla elk bericht duurzaam op en volg de afleverstatus per ontvanger; lever direct af als de ontvanger online is, sla anders op en stuur door bij herverbinding (store-and-forward).
Een schrijfzwaar toegangspatroon, met sleutel per gesprek, bevoordeelt een wide-column-opslag zoals Cassandra (hoge schrijfdoorvoer, horizontale schaal) boven één relationele database. Zodra een bericht bevestigd is afgeleverd aan alle ontvangers, kan het worden verwijderd of verlopen, omdat WhatsApp afgeleverde berichten niet oneindig serverzijdig bewaart.
5. Groepschat
Groepsmessaging is fan-out: één verzending wordt N afleveringen. Voor typische groepsgroottes is fan-out-on-write (pushen naar het afleverpad van elk lid) eenvoudig en snel te lezen. Let op de trade-off — zeer grote groepen maken fan-out-on-write duur, en dat is waarom enorme broadcastgroepen een ander ontwerpprobleem zijn.
6. Trade-offs om te benoemen
Sluit af met de spanningen: volgorde (sequentienummers per gesprek versus globale volgorde), consistentie versus beschikbaarheid voor bevestigingen (eventueel is prima voor 'laatst gezien', sterker voor aflevering), en fan-out-on-write versus on-read voor groepen. Dit expliciet benoemen maakt het antwoord senior.
Oefen het systeemontwerp van WhatsApp met realtime hulp
De system design-interviewassistent van Natively kan je gestructureerd houden tijdens een live ronde — door de volgende dimensie te suggereren en trade-offs in realtime te laten zien, allemaal op je eigen apparaat.
