Wie die Synchronisierung funktioniert

SyncEngine

SyncEngine ist die zentrale Komponente der Offline-Architektur von tikento. Sie ist verantwortlich fuer:

• Speicherung von Aenderungen in der lokalen Datenbank (IndexedDB ueber Dexie.js)
• Verfolgung von Aenderungen, die auf Synchronisierung warten (pendingSync=true)
• Senden von Aenderungen an den Server bei Wiederherstellung der Verbindung
• Empfangen von Updates vom Server (Delta Sync)
• Deduplizierung zur Vermeidung von Duplikaten

Lebenszyklus einer Aenderung

1. Erstellung einer Aenderung

Wenn Sie eine Aktion ausfuehren (z. B. Check-in eines Teilnehmers), fuehrt SyncEngine folgende Schritte aus:

1. Schreibt die Aenderung in IndexedDB mit dem Flag pendingSync=true
2. Weist den Zeitstempel clientTs zu (aktuelle Uhrzeit auf dem Geraet)
3. Erhoeht den Zaehler ausstehender Aenderungen im Indikator
4. Zeigt die Aenderung sofort in der Benutzeroberflaeche an (optimistisches Update)

2. Senden an den Server

Bei bestehender Verbindung fuehrt SyncEngine folgende Schritte aus:

1. Extrahiert alle Datensaetze mit pendingSync=true
2. Sortiert sie nach clientTs (von alt nach neu)
3. Sendet sie als Paket an den Server
4. Wartet auf Bestaetigung vom Server

3. Bestaetigung

Nach erfolgreicher Serverantwort:

1. Das Flag pendingSync wird fuer jeden gesendeten Datensatz entfernt (false)
2. Der Zaehler ausstehender Aenderungen wird reduziert
3. Wenn alle Aenderungen gesendet wurden, wechselt der Indikator auf gruen

4. Fehlerbehandlung

Bei einem Sendefehler:

1. Die Aenderungen behalten pendingSync=true
2. Ein erneuter Versuch erfolgt nach 30 Sekunden
3. Maximal 5 Versuche, danach wird der Benutzer benachrichtigt

Delta Sync

Delta Sync ermoeglicht es, vom Server nur die Daten abzurufen, die sich seit der letzten Synchronisierung geaendert haben, anstatt den gesamten Datenbestand herunterzuladen.

So funktioniert es

1. SyncEngine speichert den Zeitstempel der letzten erfolgreichen Synchronisierung in der Tabelle meta.
2. Bei der Synchronisierung wird eine Anfrage mit dem Parameter since gesendet:

GET /sync/delta?since=2026-07-15T10:30:00Z&entities=registrations,payments

3. Der Server gibt nur Datensaetze zurueck, die nach dem angegebenen Zeitpunkt geaendert wurden.
4. SyncEngine aktualisiert die lokale Datenbank und speichert den neuen Zeitstempel.

Anfrageparameter

Vorteile

• Datenverkehr sparen. Es werden nur Aenderungen uebertragen, nicht alle Daten
• Schnelligkeit. Die Synchronisierung dauert Sekunden statt Minuten
• Zuverlaessigkeit. Wenn die Synchronisierung unterbrochen wird, beginnt der naechste Versuch mit dem gleichen since

Automatische Synchronisierung

SyncEngine ueberwacht den Netzwerkstatus und startet die Synchronisierung automatisch in folgenden Faellen:

Bei Wiederherstellung der Verbindung

Wenn das Geraet von offline auf online wechselt:

1. Das online-Ereignis wird erkannt (Network Information API)
2. SyncEngine prueft die Serververfuegbarkeit (Ping)
3. Ausstehende Aenderungen werden gesendet (Upload)
4. Updates werden vom Server abgefragt (Download via Delta Sync)

Periodische Synchronisierung

Im Online-Modus prueft SyncEngine regelmaessig auf Server-Updates, damit die Daten aktuell bleiben (z. B. wenn ein anderes Teammitglied einen Check-in von einem anderen Geraet durchgefuehrt hat).

Deduplizierung

Zur Vermeidung von doppelten Aenderungen wird ein zusammengesetzter Schluessel verwendet:

clientTs + userId

Jede Aenderung wird eindeutig durch die Kombination aus Client-Zeitstempel und Benutzer-ID identifiziert. Wenn dieselbe Aenderung erneut gesendet wird (z. B. aufgrund eines Netzwerk-Timeouts), erkennt der Server das Duplikat anhand dieses Schluessels und gibt eine Bestaetigung zurueck, ohne die Aenderung erneut anzuwenden.

Das garantiert Idempotenz -- das erneute Senden desselben Aenderungspakets fuehrt nicht zu Fehlern oder Datenduplizierung.

Synchronisierungsreihenfolge

Aenderungen werden streng in chronologischer Reihenfolge nach clientTs gesendet. Das ist entscheidend fuer die Korrektheit:

• Ein Check-in eines Teilnehmers um 10:05 kann nicht durch eine Check-in-Stornierung um 10:03 ueberschrieben werden
• Eine manuelle Zahlungsbestaetigung um 11:00 wird nach der Statusaenderung um 10:55 angewendet

Wenn die Geraeteuhr von der Serverzeit abweicht, kompensiert SyncEngine die Differenz bei der ersten erfolgreichen Synchronisierung.

Umfang des lokalen Speichers

Die lokale IndexedDB-Datenbank hat Beschraenkungen, die vom Browser und Geraet abhaengen:

Fuer eine typische Veranstaltung (bis zu 2.000 Teilnehmer) betraegt das Datenvolumen 5-20 MB, was weit unter den Limits jedes Browsers liegt.

Bei Annaeherung an das Speicherlimit zeigt SyncEngine eine Warnung an und schlaegt vor, Daten abgeschlossener Veranstaltungen zu bereinigen.