Offline-first-Architektur

Warum Offline-first¶

Wi-Fi ist im Buero selbstverstaendlich. Im Feld ist Konnektivitaet Luxus.

Ein Fahrer in einer Tiefgarage, ein Lagerarbeiter in einem Betongebaeude, ein Techniker auf einem Sendedach, ein Aussendienstler im Zug — Ihre Nutzer arbeiten dort, wo das Netzwerk unzuverlaessig ist. Eine App, die bei Netzwerkausfall einen Spinner zeigt und wartet, ist nutzlos. Nutzer kehren zum Papier zurueck.

Offline-first ist kein Feature — es ist ein architektonischer Ansatz. Die lokale Datenbank ist die primaere Wahrheitsquelle. Die App reagiert sofort auf jede Interaktion. Synchronisation geschieht im Hintergrund, transparent. Der Nutzer merkt nicht, dass er offline ist — und genau das ist das Ziel.

Wo Offline-first reale Probleme loest¶

• Logistik: Fahrer bestaetigen Lieferungen, fotografieren Sendungen, scannen Codes — alles offline. Daten synchronisieren sich bei Rueckkehr zum Depot oder beim Durchfahren eines Gebiets mit Abdeckung.
• Field Service: Techniker fuellen Serviceberichte aus, laden Fotodokumentation hoch, lesen technische Dokumentation — ohne Netzwerkabhaengigkeit.
• Inventur: Tausende Artikel pro Stunde scannen. Jeder Datensatz sofort in der lokalen DB. Sync nach Schichtende.
• Vertrieb: Aussendienstler hat Katalog, Preislisten, Kundendaten — alles offline. Bestellungen werden gesendet, sobald Netzwerk verfuegbar ist.

Architektur einer Offline-first-App¶

Lokale Datenbank als primaerer Speicher¶

Alle fuer die Arbeit benoetigten Daten sind lokal. SQLite (Room auf Android, Core Data / GRDB / SwiftData auf iOS) als primaerer Speicher. Schema migriert ueber Versionierung — Datenbank-Upgrade bei App-Update ohne Datenverlust.

Fuer komplexere Szenarien verwenden wir Realm (Echtzeit-Sync integriert) oder WatermelonDB (React Native, Lazy Loading fuer grosse Datensaetze). Wahl abhaengig von Plattform, Datengroesse und Sync-Anforderungen.

Selektive Synchronisation: Nicht alle Daten muessen offline sein. Der Nutzer bekommt Daten, die fuer seine Rolle, seinen Standort und seine aktuellen Aufgaben relevant sind. Ein Fahrer hat Sendungen fuer die heutige Route, nicht das gesamte Inventar des Unternehmens.

Sync Engine¶

Synchronisation ist der schwierigste Teil der Offline-first-Architektur. Trivial fuer Read-only-Daten. Komplex fuer bidirektionalen Sync mit mehreren Nutzern.

Sync-Engine-Architektur:

1. Change Tracking — jede lokale Aenderung wird in eine Outbox-Tabelle mit Zeitstempel und Version geschrieben
2. Upload — Outbox wird in Reihenfolge an den Server gesendet, Server gibt Bestaetigung oder Konflikt zurueck
3. Download — Server sendet Aenderungen seit dem letzten Sync-Punkt (Delta Sync)
4. Apply — Heruntergeladene Aenderungen werden in die lokale DB angewendet
5. Konfliktloesung — Wenn derselbe Datensatz von zwei Nutzern geaendert wurde, werden Business-Regeln angewendet

Delta Sync: Wir synchronisieren nicht die gesamte Datenbank. Nur Aenderungen seit dem letzten erfolgreichen Sync. Zeitstempel-basierter oder Event-basierter Sync. Payload-Kompression (Protocol Buffers, MessagePack). Selbst bei langsamer EDGE-Verbindung wird der Sync in Sekunden abgeschlossen.

Konfliktloesung¶

Zwei Lagerarbeiter bearbeiten denselben Inventar-Artikel offline. Wer gewinnt?

Strategie basierend auf Geschaeftskontext:

• Last-write-wins: Einfach, deterministisch. Geeignet fuer Szenarien, in denen gleichzeitige Bearbeitung unwahrscheinlich ist (persoenliche Einstellungen, individuelle Formulare).
• Field-level Merge: Wenn Nutzer A die Adresse aenderte und Nutzer B das Telefon, werden beide Aenderungen uebernommen. Konflikt nur bei Aenderung desselben Felds.
• CRDT (Conflict-free Replicated Data Types): Fuer kollaboratives Editieren — Text, Listen, Zaehler. Mathematisch garantierte Konvergenz ohne zentrale Autoritaet.
• Custom Business Rules: „Manager-Genehmigung gewinnt immer.” „Neuere Messung ersetzt aeltere.” Regeln definiert mit einem Business-Analysten.

Schluesselprinzip: Der Nutzer verliert niemals Daten. Bei unloesarem Konflikt werden beide Versionen aufbewahrt und der Nutzer entscheidet.

Queue-Management¶

Offline durchgefuehrte Operationen werden in einer persistenten Queue eingereiht. Die Queue ueberlebt App-Neustarts, Abstuerze und sogar Updates.

Queue-Eigenschaften:

• Reihenfolge: Operationen werden in der Reihenfolge gesendet, in der sie ausgefuehrt wurden
• Retry: Exponential Backoff mit Jitter bei Fehler (1s → 2s → 4s → 8s + Zufall)
• Idempotenz: Jede Operation hat eine eindeutige ID. Backend ist idempotent — ein wiederholter Request verursacht keine Duplikate
• Prioritaet: Kritische Operationen (Lieferbestaetigung) haben Vorrang vor unkritischen (Foto)
• Transparenz: Nutzer sieht den Queue-Status — wie viele Operationen ausstehen, was gerade synchronisiert wird

Hintergrund-Sync¶

Synchronisation laeuft im Hintergrund auch wenn die App minimiert ist. iOS Background Tasks API fuer periodischen Sync. Android WorkManager fuer garantierte Ausfuehrung. Wir respektieren Batterie- und Daten-Constraints — Sync ueber Wi-Fi bevorzugt, Mobilfunk nur fuer kritische Daten.

Datenintegritaet¶

Offline-first erhoeht die Anforderungen an Datenintegritaet. Die App muss resilient sein gegen:

• Partieller Sync: Server hat 50 von 100 Datensaetzen empfangen, dann fiel das Netzwerk aus → transaktionales Batching
• Schema-Mismatch: Nutzer A hat Version 2.1, Nutzer B hat 2.0 → rueckwaertskompatibles Sync-Protokoll
• Clock Skew: Geraete haben verschiedene Zeiten → serverseitiges Timestamping fuer Reihenfolge
• Beschaedigte lokale DB: Absturz waehrend des Schreibens → WAL-Modus, Integritaets-Checks, automatische Wiederherstellung

Testing: Netzwerkbedingungs-Simulation (Charles Proxy, iOS Network Link Conditioner). Chaos Testing: zufaellige Verbindungsabbrueche, langsame Netzwerke, Paketverlust. Automatisierte Tests in CI verifizieren: null Datenverlust, null beschaedigter State, Eventual Consistency.

Technologie-Stack¶

iOS: Core Data, SwiftData, GRDB, SQLite, BackgroundTasks, URLSession Background Transfers.

Android: Room, SQLite, WorkManager, DataStore, OkHttp Interceptors.

Cross-Platform: WatermelonDB, Realm, PouchDB/CouchDB.

Sync: Custom Sync Engine, Firebase Realtime DB, Realm Sync, CouchDB Replication Protocol.

Monitoring: Sync-Erfolgsrate, Konfliktrate, Queue-Tiefe, durchschnittliche Sync-Dauer — alles in Grafana-Dashboards.

Verwandt mit