System-Design-Interview: Entwerfe WhatsApp

„Entwerfe WhatsApp" testet Echtzeit-Zustellung in massivem Maßstab, dauerhafte Nachrichtenspeicherung, Präsenz (online/zuletzt online) und das Verbindungsmanagement-Problem, Hunderte von Millionen Geräten aktiv zu halten. Wie immer will der Interviewer deine Argumentation und deine Trade-offs, keine Kopie des echten Systems.

Gehe methodisch vor: Anforderungen klären, Skalierung abschätzen, den Verbindungs- und Zustellpfad entwerfen, entscheiden, wie Nachrichten gespeichert werden, und dann Gruppenchat und die schwierigen Randfälle wie Offline-Zustellung und Reihenfolge behandeln. Der folgende Leitfaden folgt diesem Pfad.

1. Anforderungen klären

Lege zuerst den Umfang fest. Der Kern ist Eins-zu-eins-Messaging mit zuverlässiger Zustellung; kläre, ob Gruppenchat, Medien und Ende-zu-Ende-Verschlüsselung in dieser Runde zum Umfang gehören.

Funktional: Nachrichten senden/empfangen, Zustell- und Lesebestätigungen, Online-Präsenz, Gruppenchat, Offline-Zustellung, wenn ein Empfänger nicht verbunden ist.
Nicht-funktional: niedrige Latenz, hohe Verfügbarkeit, Dauerhaftigkeit (keine verlorenen Nachrichten), Reihenfolge innerhalb einer Konversation.
Klären: E2E-Verschlüsselung und Medienverarbeitung — erwähnen und explizit in oder aus dem Umfang nehmen.

2. Skalierung abschätzen

Lege die Zahlen fest, die das Design leiten. Angenommen ~2 Mrd. Nutzer und zig Milliarden Nachrichten pro Tag; das sind Hunderttausende Nachrichten pro Sekunde zur Spitzenzeit und Hunderte von Millionen gleichzeitig verbundener Geräte — das Verbindungsmanagement wird zu einem zentralen Problem.

3. Verbindungs- und Zustellpfad

Messaging braucht eine persistente Verbindung, kein Request/Response-Polling. Geräte halten einen offenen WebSocket zu einem Gateway-Server. Eine zentrale Komponente muss wissen, welches Gateway aktuell die Verbindung jedes Nutzers hält, damit eine Nachricht an den richtigen Server geroutet werden kann.

WebSocket-Gateway: hält aktive Geräteverbindungen aufrecht, verarbeitet Senden/Empfangen.
Sitzungs-/Präsenzregister: bildet Nutzer → aktuellen Gateway-Server ab (z. B. in Redis), aktualisiert bei Verbindung/Trennung.
Nachrichtenweiterleitung: das Gateway des Absenders sucht das Gateway des Empfängers und leitet weiter; ist dieser offline, wird die Nachricht in eine Warteschlange gestellt.

4. Nachrichtenspeicherung und Offline-Zustellung

Nachrichten müssen einen getrennten Empfänger überstehen. Speichere jede Nachricht dauerhaft und verfolge den Zustellstatus pro Empfänger; stelle sofort zu, wenn der Empfänger online ist, sonst speichere und leite bei Wiederverbindung weiter.

Ein schreiblastiges Zugriffsmuster mit Schlüssel pro Konversation bevorzugt einen Wide-Column-Store wie Cassandra (hoher Schreibdurchsatz, horizontale Skalierung) gegenüber einer einzelnen relationalen DB. Sobald eine Nachricht allen Empfängern bestätigt zugestellt wurde, kann sie gelöscht oder verworfen werden, da WhatsApp zugestellte Nachrichten nicht unbegrenzt serverseitig aufbewahrt.

5. Gruppenchat

Gruppen-Messaging ist Fan-out: ein Senden wird zu N Zustellungen. Für typische Gruppengrößen ist Fan-out-on-Write (Push an den Zustellpfad jedes Mitglieds) einfach und schnell zu lesen. Beachte den Trade-off — sehr große Gruppen machen Fan-out-on-Write teuer, weshalb riesige Broadcast-Gruppen ein anderes Designproblem sind.

6. Trade-offs, die man ansprechen sollte

Schließe mit den Spannungen: Reihenfolge (Sequenznummern pro Konversation vs. globale Reihenfolge), Konsistenz vs. Verfügbarkeit bei Bestätigungen (eventuell ist für „zuletzt online" in Ordnung, stärker für Zustellung), und Fan-out-on-Write vs. on-Read für Gruppen. Diese explizit zu benennen, macht die Antwort senior.

Übe WhatsApps Systemdesign mit Echtzeit-Hilfe

Der System-Design-Interview-Assistent von Natively kann dich während einer Live-Runde strukturiert halten — er schlägt die nächste zu behandelnde Dimension vor und zeigt Trade-offs in Echtzeit, alles auf deinem eigenen Gerät.