Echtzeit und Offline-Synchronisierung

Viele moderne Anwendungen fühlen sich lebendig an: Eine Chatnachricht erscheint sofort, der Status einer Bestellung aktualisiert sich von selbst, mehrere Personen bearbeiten gleichzeitig dasselbe Dokument. Andere Anwendungen funktionieren auch ohne Netz: Eine Notiz-App im Flugzeug, eine Handwerker-App im Keller ohne Empfang, eine Lern-App in der U-Bahn. Beide Muster – Echtzeit und Offline-Fähigkeit – verändern die Architektur grundlegend, weil die klassische Vorstellung „Client fragt, Server antwortet“ nicht mehr ausreicht. Diese Lektion zeigt die gängigen Techniken und die typischen Herausforderungen, vor allem den Umgang mit Konflikten, wenn Daten an mehreren Orten gleichzeitig geändert werden.

1. Echtzeit: drei Techniken

Damit ein Client von Neuigkeiten erfährt, gibt es drei grundsätzliche Wege. Probieren Sie sie aus:

Für viele Anwendungsfälle ist Polling völlig ausreichend und wird unterschätzt. Eine Statusanzeige für eine Paketsendung muss nicht in Millisekunden aktualisiert werden; eine Abfrage alle dreißig Sekunden ist einfach, cachebar und funktioniert hinter jeder Firewall. Server-Sent Events sind die richtige Wahl, wenn Daten nur in eine Richtung fließen, und sie funktionieren über normales HTTP, inklusive automatischer Wiederverbindung. WebSockets lohnen sich, wenn Nachrichten in beide Richtungen häufig und schnell fließen müssen, etwa in einem Chat oder bei gemeinsamem Bearbeiten.

2. Echtzeit skalieren

Dauerhafte Verbindungen bringen eine besondere Herausforderung mit sich: Jede Verbindung hängt an einem bestimmten Server. Wenn Nutzer A mit Server 1 und Nutzer B mit Server 2 verbunden ist, muss eine Nachricht von A irgendwie zu Server 2 gelangen. Klicken Sie sich durch die übliche Lösung:

Wichtig ist außerdem der Umgang mit Verbindungsabbrüchen. Mobile Verbindungen reißen ständig ab, beim Wechsel ins WLAN, im Tunnel, im Aufzug. Ein Client muss sich automatisch neu verbinden und dabei nachholen, was er verpasst hat, etwa indem er die Kennung der letzten empfangenen Nachricht mitschickt. Die Echtzeitverbindung ist deshalb nie die einzige Quelle der Wahrheit, sondern ein schneller Benachrichtigungskanal; der verlässliche Stand liegt in der Datenbank.

3. Offline first

Die meisten Web-Anwendungen sind „online first“: Ohne Verbindung geht nichts. Bei Offline-first-Anwendungen ist es umgekehrt. Die Oberfläche liest und schreibt immer lokal, was sie auch bei gutem Netz extrem schnell macht. Änderungen landen in einer Warteschlange und werden hochgeladen, sobald eine Verbindung besteht.

Abb. 1.1Aufbau einer Offline-first-Anwendung

Im Browser stehen dafür IndexedDB als lokale Datenbank und Service Worker zur Verfügung, mit denen Seiten und Daten auch ohne Netz geladen werden können. In mobilen Apps übernimmt oft SQLite diese Rolle. Für die Synchronisation gibt es fertige Lösungen, doch die entscheidende Frage bleibt dieselbe: Was passiert, wenn dieselben Daten an zwei Orten verschieden geändert wurden?

4. Konflikte lösen

Konflikte sind bei Offline-Fähigkeit und gemeinsamer Bearbeitung unvermeidlich. Probieren Sie verschiedene Regeln aus:

„Letzte Änderung gewinnt“ ist die einfachste Regel, verliert aber still Daten – und verlässt sich auf Uhren verschiedener Geräte, die nie ganz genau gehen. Feldweises Zusammenführen löst die meisten Fälle ohne Verlust. Für Texte, die mehrere Personen gleichzeitig bearbeiten, gibt es spezielle Datenstrukturen, sogenannte CRDTs (Conflict-free Replicated Data Types), die Änderungen mathematisch garantiert konfliktfrei zusammenführen. Sie stecken hinter vielen Werkzeugen für gemeinsames Schreiben. Und in manchen Fällen ist die ehrlichste Lösung, den Nutzer entscheiden zu lassen.

5. Was sich offline nicht lösen lässt

Nicht alles kann offline funktionieren. Eine Buchung für den letzten freien Platz im Yogakurs muss vom Server bestätigt werden, sonst verkaufen zwei Geräte denselben Platz. Solche Vorgänge werden offline als „vorgemerkt“ angezeigt und erst nach dem Abgleich endgültig. Die Oberfläche muss diesen Zustand klar zeigen: gespeichert auf dem Gerät, übertragen, bestätigt oder abgelehnt. Nutzer akzeptieren Einschränkungen gut, wenn sie verständlich sind; sie sind frustriert, wenn eine scheinbar erfolgreiche Aktion später stillschweigend verschwindet.

6. Ein Beispiel

Ein Fahrradverleih stattet seine Mitarbeiter an den Stationen mit einer App aus, mit der sie Räder ausgeben, zurücknehmen und Schäden dokumentieren. Viele Stationen liegen an Uferwegen mit schlechtem Empfang. Die App wird deshalb offline first gebaut: Räder, Reservierungen des Tages und Checklisten liegen lokal, Schäden mit Fotos werden auf dem Gerät gespeichert und hochgeladen, sobald Netz besteht. Die Rückgabe eines Rades ist ein Ereignis, das nicht verloren gehen darf; jede Rückgabe bekommt eine eindeutige Kennung, damit ein doppelter Upload nicht zu zwei Buchungen führt. Die Zentrale sieht über Server-Sent Events live, welche Räder gerade unterwegs sind. Neue Reservierungen für bereits ausgegebene Räder werden nur online angenommen. So funktioniert die App am Wasser genauso zuverlässig wie im Büro, und die Zentrale behält trotzdem den Überblick.

7. Worauf es im Entwurf ankommt

Wer Echtzeit- oder Offline-Funktionen plant, sollte einige Fragen früh beantworten. Wie aktuell müssen die Daten wirklich sein – Millisekunden, Sekunden oder Minuten? Oft genügt weniger, als man zunächst denkt, und die einfachere Technik spart viel Aufwand. Wie viele gleichzeitige Verbindungen sind zu erwarten? Zehntausend offene WebSockets brauchen andere Server-Einstellungen und ein anderes Lastverteilungskonzept als zehntausend kurze Anfragen. Welche Daten müssen offline verfügbar sein, und wie viel Speicher darf die App auf dem Gerät belegen? Und schließlich: Welche Vorgänge dürfen offline nur vorgemerkt werden, weil sie eine Bestätigung vom Server brauchen?

Auch der Betrieb verdient Aufmerksamkeit. Dauerhafte Verbindungen erschweren Deployments, denn beim Neustart eines Servers brechen alle seine Verbindungen ab. Clients müssen sich deshalb gestaffelt und mit zufälliger Verzögerung neu verbinden, sonst trifft eine Welle von Wiederverbindungen gleichzeitig auf die übrigen Server. Offline-Apps wiederum laufen in vielen Versionen gleichzeitig, weil nicht jedes Gerät sofort aktualisiert wird. Das Format der synchronisierten Daten muss deshalb abwärtskompatibel bleiben, genau wie bei einer öffentlichen API. Wer diese Punkte von Anfang an bedenkt, erspart sich schwer zu findende Fehler, die nur bei bestimmten Geräten, Netzen oder Versionen auftreten.

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