Offline-First ist kein Feature, sondern eine Architektur
Wie eine idempotente Schreib-Queue dafür sorgt, dass eine App auch ohne Netz funktioniert.
Geschrieben von KillaQ
Im Aufzug, in der Bahn oder in Gegenden mit lückenhafter Abdeckung ist das Netz kein Sonderfall — es ist der Normalzustand. Eine App, die dauerhafte Konnektivität voraussetzt, fällt nicht gelegentlich aus; sie fällt genau dann aus, wenn der Nutzer sie am dringendsten braucht.
Offline als Fehlerzustand zu behandeln ist der Fehler
Die übliche Umsetzung packt jede Anfrage in ein try/catch, zeigt „keine Verbindung" und verliert, was der Nutzer gerade eingegeben hat. Das ist keine Offline-Unterstützung, sondern die Ankündigung, dass es keine gibt.
Offline-First dreht das Verhältnis um. Die Quelle der Wahrheit für den Nutzer ist das Gerät. Das Netz ist ein Synchronisationsmechanismus, der langsam sein, ausfallen und in falscher Reihenfolge ankommen darf.
Die Outbox-Queue
Das zentrale Muster ist eine dauerhafte Schreib-Queue:
- Die Aktion des Nutzers wird sofort auf den lokalen Zustand angewendet und persistiert.
- Die Absicht wird als Operation mit eigener Kennung in die Queue gestellt.
- Ein Hintergrundprozess leert die Queue, sobald das Netz zurück ist — mit Wiederholungen und exponentiellem Backoff.
- Die Serverantwort gleicht den lokalen Zustand ab.
Entscheidend ist: Schritt 1 hängt nie von Schritt 3 ab.
Idempotenz oder Duplikate
Wenn der Client eine Operation erneut sendet, weil er die Antwort nicht erhalten hat — nicht weil die Anfrage den Server nie erreichte —, entsteht ein Duplikat. Die Lösung ist kein Raten: Der Client erzeugt pro Operation eine eindeutige Kennung, der Server behandelt sie als Schlüssel. Kommt dieselbe Kennung ein zweites Mal an, liefert der Server das ursprüngliche Ergebnis zurück, statt einen weiteren Datensatz anzulegen.
Ohne das erzeugt ein instabiles Netz doppelte Belege, wiederholte Abbuchungen und Phantom-Bestellungen.
Konflikte: vorher entscheiden
Zwei Geräte bearbeiten offline denselben Datensatz. Beim Synchronisieren gewinnt einer. „Last write wins" ist eine gültige Entscheidung, wenn sie ausgesprochen ist; sie ist keine mehr, wenn sie zufällig passiert.
Für die meisten Geschäftsfälle ist es am besten, den Konflikt per Design zu vermeiden: Operationen, die addieren statt überschreiben, und Felder mit einem klaren Eigentümer.
Was zu testen ist
Keine dieser Garantien lässt sich bei guter Verbindung prüfen. Testen Sie im Flugmodus mitten im Schreibvorgang, mit beendeter App während der Synchronisation und mit verstellter Geräteuhr. Genau dort tauchen die Duplikate auf.