Real-Time-Features entwickeln

„Real-Time" ist ein weites Feld – eine Chat-App, ein Live-Dashboard, Präsenzanzeigen und kollaborative Cursor haben sehr unterschiedliche Anforderungen. Wer das falsche Transportprotokoll oder die falsche Architektur wählt, baut Features, die in der Demo funktionieren und unter echter Last auseinanderfallen. Die gute Nachricht: Die meisten Real-Time-Anforderungen lassen sich sauber auf wenige gut verstandene Muster abbilden. Hier ist die Entscheidungshilfe.

Transport und Anforderung zusammenbringen

Die erste Frage lautet: Fließen Daten in eine Richtung (Server zum Client) oder in beide?

• Server-Sent Events (SSE): ein einfacher, unidirektionaler Stream vom Server zum Client über gewöhnliches HTTP. Ideal für Benachrichtigungen, Live-Feeds, Aktivitäts-Streams und Dashboards. SSE verbindet sich automatisch neu, funktioniert durch die meisten Proxys und ist deutlich einfacher als WebSockets. Wird zu selten eingesetzt – und ist häufig die richtige Antwort.
• WebSockets: eine persistente, vollduplexfähige Verbindung für echte bidirektionale Kommunikation mit niedriger Latenz. Die richtige Wahl für Chat, Multiplayer, kollaboratives Editieren und Live-Cursor – also alles, bei dem auch der Client häufig sendet.
• Polling / Long-Polling: der Server wird wiederholt abgefragt. Primitiv, aber gelegentlich die pragmatische Wahl bei seltenen Updates oder eingeschränkten Umgebungen. Nicht als Standard-Ansatz verwenden.

Die Faustregel: Wenn Clients nur empfangen, SSE nutzen; wenn Clients auch ständig senden, WebSockets.

Nicht von Grund auf neu bauen, wenn es nicht nötig ist

Persistente Verbindungen sind schnell aufgebaut, aber aufwendig zu betreiben. Bevor man einen eigenen WebSocket-Server schreibt, sollten verwaltete Schichten in Betracht gezogen werden, die die schwierigen Teile lösen (Skalierung, Präsenz, Fan-out, Reconnection):

• Supabase Realtime – wer bereits auf Postgres setzt, kann damit Datenbankänderungen und Präsenz über WebSockets mit nahezu keinem Server-Code übertragen
• Verwaltete Pub/Sub-Dienste (Pusher, Ably und ähnliche) übernehmen Connection-Skalierung und Zustellgarantien
• Das verwendete Framework bietet möglicherweise eine vollständige Lösung, die sich lohnt zu nutzen

Eine eigene Implementierung ist dann gerechtfertigt, wenn sehr spezifische Anforderungen oder Skaleneffekte dies verlangen – nicht als Standard.

Die Architektur, die skaliert

Das Schwierige an Real-Time ist nicht eine einzelne Verbindung, sondern zehntausend. Ein einzelner Server kann nur eine begrenzte Anzahl von Verbindungen halten – und sobald mehrere Server laufen, muss ein Client, der mit Server A verbunden ist, auch Nachrichten empfangen, die auf Server B veröffentlicht wurden.

Die bewährte Lösung ist ein Pub/Sub-Backbone (häufig Redis) hinter den Connection-Servern:

1. Connection-Server halten die WebSocket/SSE-Verbindungen der Clients
2. Wenn etwas passiert, wird es in einem Channel auf der Pub/Sub-Schicht veröffentlicht
3. Jeder Connection-Server abonniert diese Schicht und leitet Nachrichten an die jeweils relevanten Clients weiter

So wird „wer ist wo verbunden" von „was muss verteilt werden" entkoppelt – und Connection-Server lassen sich horizontal skalieren. Verwaltete Real-Time-Dienste implementieren dieses Muster, sodass man es selbst nicht entwickeln muss.

Mit der Realität umgehen

Real-Time-Features stehen und fallen mit ihrem Umgang mit Fehlerzuständen:

• Reconnection. Verbindungen brechen ständig ab (Mobilfunknetze, Ruhezustand, Proxys). Clients müssen sich automatisch mit Backoff neu verbinden.
• Verpasste Nachrichten. Nach einer erneuten Verbindung kann der Client Updates verpasst haben. Nachholen unterstützen – Updates seit einem Cursor/Zeitstempel erneut senden oder den Zustand beim Reconnect neu laden.
• Präsenz. „Wer ist online" erfordert Heartbeats und Timeouts, um stille Verbindungsabbrüche zu erkennen.
• Reihenfolge und Konflikte. Bei kollaborativen Features muss festgelegt werden, wie gleichzeitige Bearbeitungen aufgelöst werden (Last-Write-Wins oder CRDTs/OT für echte kollaborative Texteditierung).
• Authentifizierung. Die Verbindung beim Handshake authentifizieren und jedes Abonnement autorisieren – den Channel-Angaben des Clients nicht vertrauen.

Der pragmatische Weg

Den einfachsten Transport verwenden, der die Anforderungen erfüllt (SSE deutlich häufiger, als Teams annehmen), auf eine verwaltete Real-Time-Schicht setzen, solange kein triftiger Grund dagegen spricht, und Reconnection sowie verpasste Nachrichten von Anfang an einplanen. Die meisten „Real-Time ist schwierig"-Horrorgeschichten entstehen dadurch, dass dieser letzte Punkt übersprungen wird.

Wer Real-Time-Features hinzufügen möchte und eine Architektur sucht, die auch nach der Demo zuverlässig bleibt: Sprechen wir darüber.