Offline Queue: Prinzipien, Strategien und Arbeitsmechanismen

Was ist eine Offline-Warteschlange?

Offline Queue ist eine geordnete Sammlung von Operationen (Erstellen, Aktualisieren, Löschen), die die Anwendung lokal speichert, wenn das Gerät keinen Netzwerkzugriff hat. Sobald die Verbindung wiederhergestellt ist, sendet die Warteschlange die Operationen in derselben Reihenfolge an den Server, in der der Benutzer sie ausgeführt hat.

Stellen Sie sich ein Szenario vor: Ein Messenger-Benutzer tippt in der U-Bahn ohne Internet Nachrichten. Jedes Tippen auf „Senden“ wird zur Offline Queue hinzugefügt. Wenn der Zug den Tunnel verlässt und das Netzwerk verfügbar ist, werden alle Nachrichten automatisch gesendet. Benutzererfahrung — nahtlos: Er bemerkt nicht, dass er offline war, abgesehen von einer leichten Verzögerung beim Senden.

Laut Uber Engineering (2024) verarbeitet deren Offline-Warteschlange über 2 Millionen Operationen pro Tag in Regionen mit schlechter Verbindungsqualität. Die Warteschlange verwendet lokalen Room-Speicher mit FIFO-Reihenfolge und einem Exactly-Once-Zustellungsmechanismus.

data class QueuedOperation(
    val id: String,
    val type: OperationType,
    val endpoint: String,
    val payload: String,
    val timestamp: Long,
    val retryCount: Int = 0,
    val idempotencyKey: String
)

Jede Operation enthält alle für die erneute Sendung erforderlichen Daten: Endpunkt, Anforderungstext, Zeitstempel und idempotencyKey. Room-Datenbank garantiert die Persistenz der Warteschlange bei App-Neustarts und OS-Abstürzen.

Warum eine Operationswarteschlange in einer mobilen App benötigt wird

Zustellungsgarantie — der Hauptzweck der Warteschlange. Der Benutzer muss sicher sein, dass seine Aktion (Nachricht senden, Like, Bestellung) abgeschlossen wird, selbst wenn das Netzwerk in diesem Moment nicht verfügbar ist. Offline Queue mit Wiederholungsmechanismus gewährleistet die letztendliche Zustellung.

Verbesserte UX bei schlechter Konnektivität — laut GSMA Mobile Economy Report (2025) haben etwa 40% der mobilen Nutzer weltweit instabile Internetverbindungen. Offline Queue macht die App in U-Bahnen, Aufzügen, abgelegenen Gebieten nutzbar — überall dort, wo die Konnektivität unterbrochen ist.

Reduzierter Datenverlust — ohne Warteschlange gehen alle offline durchgeführten Aktionen verloren. Ein Benutzer könnte ein langes Formular ausfüllen, auf „Senden“ tippen und einen Netzwerkfehler sehen — die gesamte Eingabe ist verloren. Offline Queue speichert Daten und sendet sie bei der ersten Gelegenheit. Auto-Save in Google Docs ist ein klassisches Beispiel einer Offline-Warteschlange für Dokumente.

Asynchrone Synchronisation — die Warteschlange erlaubt der App, die UI während des Sendens nicht zu blockieren. Der Benutzer arbeitet weiter, während der Sync-Manager die Warteschlange im Hintergrund verarbeitet. Dies folgt den Prinzipien der Reaktiven Architektur und verbessert die Reaktionsfähigkeit der Oberfläche.

Architektur der Offline-Warteschlange: Speicherung und Verarbeitung

Drei Schichten der Warteschlange: Speicher (Persistenz), Scheduler und Ausführer. Speicher — Room mit einer QueuedOperation-Tabelle. Scheduler — WorkManager (Android) oder BGTaskScheduler (iOS), der die Synchronisation startet, wenn das Netzwerk verfügbar wird. Ausführer — ein sequenzieller FIFO-Iterator, der Operationen eine nach der anderen sendet.

Verarbeitungsreihenfolge — entscheidend für die Datenkonsistenz. Wenn ein Benutzer einen Datensatz erstellt und dann bearbeitet hat, müssen beide Operationen in derselben Reihenfolge gesendet werden. Andernfalls erhält der Server zuerst ein Update für einen nicht existierenden Datensatz — ein Fehler. Sequenzielles FIFO — strenge Reihenfolge mit Abhängigkeitskontrolle zwischen Operationen.

Zusammenführungsstrategie — wenn die Warteschlange ein CREATE und unmittelbar danach ein DELETE desselben Objekts enthält, können beide Operationen ohne Sendung entfernt werden: Der Endzustand ist, dass das Objekt nicht erstellt wurde. Ebenso können CREATE + UPDATE zu einem einzigen CREATE mit den neuesten Daten zusammengeführt werden. Warteschlangenoptimierung reduziert die Anzahl der HTTP-Anfragen und beschleunigt die Synchronisation.

Laut Android Developers (2025) ist WorkManager die bevorzugte Methode zur Handhabung von Offline Queue auf Android: Es garantiert die Ausführung selbst nach einem Geräteneustart, unterstützt Netzwerkbeschränkungen und ermöglicht die Konfiguration von Wiederholungsrichtlinien über NetworkType.CONNECTED.

class SyncWorker(
    private val context: Context,
    private val params: WorkerParameters
) : CoroutineWorker(context, params) {

    override suspend fun doWork(): Result = runCatching {
        queueRepository.processNextBatch(batchSize = 10)
        Result.success()
    }.getOrDefault(Result.retry())
}

CoroutineWorker verarbeitet Operationsstapel und gibt bei Fehler Result.retry() zurück — WorkManager wiederholt automatisch mit exponentiellem Backoff. Dies ist der einfachste Weg, eine zuverlässige Offline Queue auf Android zu erhalten.

Wiederholungsstrategien: exponential backoff und Wiederholungsrichtlinie

Exponential Backoff — eine Standard-Wiederholungsstrategie mit zunehmenden Intervallen: 2 Sek., 4 Sek., 8 Sek., 16 Sek. und so weiter bis zu einem maximalen Schwellenwert. Dies verhindert wiederholte Serverüberlastung, wenn dieser vorübergehend nicht verfügbar ist. Die Java-Bibliothek Resilience4j (2024) bietet eine fertige Retry-Implementierung mit konfigurierbarem Backoff.

Maximale Anzahl von Versuchen — ein kritischer Parameter. Wenn nach 5–10 Versuchen die Operation fehlschlägt, sind weitere Wiederholungen verschwenderisch und nutzlos. Eine Dead Letter Queue wird empfohlen: Nach Erschöpfung der Versuche wird die Operation zur manuellen Analyse in eine separate Tabelle verschoben. Laut Microsoft Patterns & Practices (2024) vereinfacht eine Dead Letter Queue das Debuggen von Synchronisationsproblemen und verhindert, dass fehlerhafte Operationen die Warteschlange blockieren.

Jitter — zufällige Variation — Hinzufügen einer Zufallszahl zum Backoff-Intervall. Wenn tausend Geräte gleichzeitig nach einer Unterbrechung das Netzwerk wiederherstellen, beginnen alle gleichzeitig mit der Synchronisation. Jitter verteilt sie zeitlich und verhindert Cache Stampede auf dem Server. Vollständiger Jitter: delay = random(0, backoff) — von AWS (2024) für API-Clients empfohlen.

Konfliktlösung: Wie man Datenkollisionen auflöst

Last Write Wins (LWW) — die einfachste Strategie: Bei einem Konflikt gewinnt die Operation mit dem späteren Zeitstempel. LWW erfordert Zeitsynchronisation — der Zeitstempel muss auf dem Server generiert werden oder eine logische Uhr (Lamport-Uhren) verwenden. Nachteil: Die Daten eines Benutzers können ohne Warnung von den Daten eines anderen Benutzers überschrieben werden.

OT (Operational Transformation) — der Algorithmus, der von Google Docs und Figma für die Echtzeit-Zusammenarbeit verwendet wird, einschließlich des Offline-Modus. OT transformiert Operationen, sodass sie auf jeden Dokumentzustand angewendet werden können, und gewährleistet Konsistenz ohne Sperren. CRDT (Conflict-Free Replicated Data Types) — eine Alternative zu OT, die in mobilen Apps an Popularität gewinnt: Daten sind so strukturiert, dass Konflikte ohne zentralen Server mathematisch lösbar sind.

Benutzerdefinierte Zusammenführung — für Apps mit einfachen Datenmodellen (Notizen, Kontakte) können benutzerdefinierte Zusammenführungsregeln implementiert werden. Zum Beispiel für eine Notiz: Wenn der Text in zwei Versionen geändert wurde, führen Sie sie als Verkettung mit einem Trennzeichen zusammen. Vom Benutzer gelöster Konflikt — wenn eine automatische Zusammenführung unmöglich ist, zeigen Sie dem Benutzer beide Versionen und lassen Sie ihn wählen. Dropbox (2024) verwendet diesen Ansatz für Offline-Dateikonflikte und erstellt Kopien mit dem Präfix „Conflicted Copy“.

Idempotency Keys — Schutz vor Duplikaten

Idempotency Key — ein eindeutiger Operationsbezeichner, den der Server zur Erkennung doppelter Anfragen verwendet. Wenn der Client dieselbe Anfrage mit demselben Schlüssel sendet, gibt der Server das Ergebnis der bereits abgeschlossenen Operation zurück, ohne sie erneut auszuführen. Dies ist für Offline Queue von entscheidender Bedeutung, wo aufgrund von Netzwerkfehlern erneute Sendungen möglich sind.

Das Format des Idempotency Keys ist eine UUID oder ein Hash der Anforderungsparameter. Der Server muss abgeschlossene Schlüssel zusammen mit dem Ergebnis für einige Zeit (normalerweise 24 Stunden) speichern, um Duplikate zu erkennen. Die Stripe-API (2024) ist das Referenzbeispiel: Der Schlüssel wird im Idempotency-Key-Header übergeben, und wiederholte Anfragen mit demselben Schlüssel geben eine zwischengespeicherte Antwort zurück.

Clientseitige Generierung — der Schlüssel wird auf dem Client vor dem Senden der Operation erstellt und in der QueuedOperation-Tabelle gespeichert. Bei Wiederholung ändert sich der Schlüssel nicht. Exactly-Once-Architektur — die Kombination eines Idempotency Keys auf dem Client und der Deduplizierung auf dem Server ist der einzige Weg, um zu garantieren, dass eine Operation nicht zweimal ausgeführt wird.

fun createOperation(type: OperationType, payload: String): QueuedOperation =
    QueuedOperation(
        id = UUID.randomUUID().toString(),
        type = type,
        endpoint = type.endpoint,
        payload = payload,
        timestamp = currentTimeMillis(),
        idempotencyKey = UUID.randomUUID().toString()
    )

Jede Operation erhält zwei UUIDs: eine — der Datensatzbezeichner in der Warteschlange, die zweite — der Idempotency Key für den Server. Serverseitige Deduplizierung durch idempotencyKey garantiert, dass die Bestellung auch bei erneuter Sendung nicht dupliziert wird.