How Synchronization Works

SyncEngine

SyncEngine is the central component of tikento's offline architecture. It is responsible for:

• Saving changes to the local database (IndexedDB via Dexie.js)
• Tracking changes awaiting synchronization (pendingSync=true)
• Sending changes to the server when connectivity is restored
• Receiving updates from the server (delta sync)
• Deduplication to prevent duplicates

Lifecycle of a Change

1. Creating a Change

When you perform an action (e.g., checking in a participant), SyncEngine:

1. Writes the change to IndexedDB with the pendingSync=true flag
2. Assigns a clientTs timestamp (current time on the device)
3. Increments the pending changes counter in the indicator
4. Immediately reflects the change in the interface (optimistic update)

2. Sending to the Server

When a connection is available, SyncEngine:

1. Retrieves all records with pendingSync=true
2. Sorts them by clientTs (oldest first)
3. Sends them as a batch to the server
4. Waits for server confirmation

3. Confirmation

After a successful server response:

1. The pendingSync flag is removed (false) for each sent record
2. The pending changes counter decreases
3. If all changes have been sent, the indicator switches to green

4. Error Handling

On a send error:

1. Changes remain with pendingSync=true
2. A retry is attempted after 30 seconds
3. Maximum of 5 attempts, after which the user is notified

Delta Sync

Delta sync allows receiving only data that has changed since the last synchronization from the server, instead of downloading the entire dataset.

How It Works

1. SyncEngine stores the timestamp of the last successful synchronization in the meta table.
2. During synchronization, a request is sent with a since parameter:

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

3. The server returns only records modified after the specified time.
4. SyncEngine updates the local database and saves the new timestamp.

Request Parameters

Benefits

• Bandwidth savings. Only changes are transmitted, not all data
• Speed. Synchronization takes seconds, not minutes
• Reliability. If synchronization is interrupted, the next attempt starts from the same since

Automatic Synchronization

SyncEngine monitors network status and automatically triggers synchronization in the following cases:

On Connectivity Restore

When the device transitions from offline to online:

1. An online event is detected (Network Information API)
2. SyncEngine checks server availability (ping)
3. Pending changes are sent (upload)
4. Updates are requested from the server (download via delta sync)

Periodic Synchronization

While online, SyncEngine periodically checks for server updates to keep data current (e.g., if another team member checked in a participant from a different device).

Deduplication

To prevent duplicate changes, a composite key is used:

clientTs + userId

Each change is uniquely identified by the combination of the client-side creation timestamp and the user identifier. If the same change is sent again (e.g., due to a network timeout), the server recognizes the duplicate by this key and returns a confirmation without applying it again.

This guarantees idempotency -- resending the same set of changes does not cause errors or data duplication.

Synchronization Order

Changes are sent strictly in chronological order by clientTs. This is critical for correctness:

• A participant check-in at 10:05 cannot be overwritten by a check-in cancellation at 10:03
• A manual payment mark at 11:00 is applied after a status change at 10:55

If the device clock differs from the server time, SyncEngine compensates for the difference during the first successful synchronization.

Local Storage Limits

The local IndexedDB database has limits that depend on the browser and device:

For a typical event (up to 2,000 participants), data volume is 5-20 MB, which is well within any browser's limits.

When approaching the storage limit, SyncEngine displays a warning and offers to clear data from completed events.