Fallstudie: Chat-Anwendung

Chat-Anwendungen gehören zu den beliebtesten Entwurfsaufgaben, weil sie viele Themen dieses Kurses verbinden: dauerhafte Verbindungen, Echtzeit-Zustellung über mehrere Server, Reihenfolge und Zustellgarantien, Offline-Nutzer, Push-Benachrichtigungen und große Datenmengen. Gleichzeitig sind die Erwartungen der Nutzer hoch – eine Nachricht, die nicht sofort ankommt oder doppelt erscheint, fällt sofort auf. Diese Fallstudie entwirft eine Chat-Anwendung für Einzel- und Gruppengespräche, wie sie etwa ein Sportverein, eine Schule oder ein Unternehmen intern einsetzen könnte.

1. Anforderungen

Funktional: Einzel- und Gruppenchats mit bis zu 500 Mitgliedern, Textnachrichten und Bilder, Zustell- und Lesestatus, Online-Anzeige, Push-Benachrichtigungen, Verlauf auf allen Geräten einer Person. Nicht funktional: Nachrichten erscheinen bei Online-Empfängern in unter einer Sekunde, gehen nie verloren, erscheinen in der richtigen Reihenfolge und nicht doppelt. Die Anwendung muss mit wackeligen Mobilverbindungen umgehen. Bewusst ausgeklammert werden zunächst Sprach- und Videoanrufe, die eigene Infrastruktur verlangen.

2. Überschlag

Die Zahlen zeigen, wo die Herausforderung liegt: nicht in der Zahl der Nachrichten, die eine gute Datenbank problemlos schreibt, sondern in der Zahl gleichzeitig offener Verbindungen. Jede Verbindung belegt Speicher und muss am Leben gehalten werden. Deshalb trennt man die Verbindungsserver, die nur Verbindungen halten und Nachrichten durchreichen, von den Diensten, die Nachrichten speichern und verarbeiten.

3. API und Datenmodell

Über die WebSocket-Verbindung laufen wenige Nachrichtentypen: senden, empfangen, Zustellung bestätigen, Tippen anzeigen. Für den Verlauf gibt es eine normale HTTP-Schnittstelle, etwa GET /gespraeche/:id/nachrichten?vor=1234. Das Datenmodell: Gespräche, Mitgliedschaften und Nachrichten. Jede Nachricht erhält vom Server eine fortlaufende Nummer innerhalb ihres Gesprächs – so ist die Reihenfolge eindeutig, auch wenn Uhren von Geräten abweichen. Zusätzlich schickt der Client eine eigene, zufällige Kennung mit, damit ein wiederholtes Senden nach einem Verbindungsabbruch nicht zu einer doppelten Nachricht führt. Zu jeder Mitgliedschaft wird gespeichert, bis zu welcher Nummer gelesen wurde; daraus ergeben sich ungelesene Nachrichten und Lesestatus.

4. Architektur

Abb. 2.1Architektur einer Chat-Anwendung

5. Vertiefung

Wiederverbindung: Mobile Clients verlieren ständig die Verbindung. Beim Wiederverbinden schickt der Client je Gespräch die letzte bekannte Nummer und erhält alles Fehlende. Die Echtzeitverbindung ist damit nur ein Beschleuniger, nie die einzige Quelle. Präsenz: Der Online-Status wird in Redis mit kurzer Lebensdauer gehalten und durch regelmäßige Lebenszeichen der Clients erneuert; er muss nicht perfekt sein, sollte aber das System nicht belasten – bei großen Gruppen zeigt man ihn nur auf Anfrage. Große Gruppen: Eine Nachricht an 500 Mitglieder erzeugt 500 Zustellungen. Deshalb wird pro Gespräch, nicht pro Empfänger verteilt, und Push-Benachrichtigungen werden gebündelt. Bilder: Dateien gehen nicht über die WebSocket-Verbindung, sondern per signierter URL direkt in den Objektspeicher; in der Nachricht steht nur der Verweis.

6. Abwägungen

Die letzte Zeile verdient einen Hinweis. Ende-zu-Ende-Verschlüsselung ist für private Messenger heute Standard und für vertrauliche Kommunikation, etwa in einer Arztpraxis, sehr wünschenswert. Sie verändert aber die Architektur grundlegend: Suche, Moderation und Wiederherstellung auf neuen Geräten müssen anders gelöst werden. Für einen internen Vereins- oder Unternehmenschat genügt oft Transportverschlüsselung mit verschlüsselter Speicherung – die Entscheidung sollte bewusst und dokumentiert fallen.

7. Varianten der Aufgabe

Chat-Anwendungen gibt es in vielen Ausprägungen, und jede verschiebt die Schwerpunkte. Ein Kundenservice-Chat auf der Website eines Onlineshops hat wenige gleichzeitige Gespräche, aber Anforderungen an Zuweisung, Wartezeiten und Übergabe zwischen Beschäftigten im Kundendienst; oft beantwortet zuerst ein KI-Assistent und übergibt bei Bedarf an einen Menschen. Ein Chat in einer Lern-App für Schulklassen braucht Moderation, Meldefunktionen und besonders strenge Datenschutzregeln. Ein Live-Chat zu einem Sportereignis mit Zehntausenden Zuschauern in einem einzigen Raum verlangt ganz andere Techniken: Dort wird nicht jede Nachricht zuverlässig an jeden zugestellt, sondern ausgedünnt und gestreamt, weil niemand Hunderte Nachrichten pro Sekunde lesen kann.

Auch die Frage der Suche verändert den Entwurf. Sollen Nutzer ihren gesamten Verlauf durchsuchen können, braucht es einen Suchindex, der mit jeder neuen Nachricht aktualisiert wird und die Rechte berücksichtigt – niemand darf Treffer aus Gesprächen sehen, an denen er nicht beteiligt ist. Mit Ende-zu-Ende-Verschlüsselung muss diese Suche dagegen auf dem Gerät selbst stattfinden.

8. So präsentieren Sie den Entwurf

Bei einer Chat-Aufgabe erwarten Zuhörer vor allem eine Antwort auf drei Fragen: Wie kommt eine Nachricht zuverlässig an? Wie wird die Reihenfolge sichergestellt? Und was passiert mit Nutzern, die gerade offline sind? Wer diese drei Fragen früh und klar beantwortet, hat den Kern der Aufgabe gelöst. Details wie Präsenz, Tippanzeige oder Lesebestätigungen sind wichtig, aber zweitrangig. Hilfreich ist es, den Weg einer einzelnen Nachricht einmal vollständig durchzuerzählen – vom Tippen auf „Senden“ bis zum Häkchen beim Empfänger – und dabei auf jeder Station zu erklären, was passiert, wenn genau hier etwas schiefgeht. Dieser Blick auf Fehlerfälle unterscheidet einen durchdachten Entwurf von einer bloßen Skizze.

Stand: September 2026. Kursmaterial der Klarwerk Akademie. Zahlen zu Latenzen und Kosten sind Größenordnungen zur Orientierung, keine Messwerte.