Handling offline-first state sync and badge queueing for an enterprise Visitor Management System

Hi all,

We are designing the edge-to-cloud sync pipeline for an enterprise visitor management system designed to run on dedicated self-service reception kiosks and tablet terminals.

The Problem

During network flaps or ISP degradation at facility entrances, the check-in kiosks must operate completely offline:

1. Accept check-in data, capture visitor photos, and issue temporary visitor badges locally.

2. Queue badge issuance events and cryptographic visitor tokens locally (in an encrypted SQLite/IndexedDB store).

3. Re-sync bidirectionally with the central PostgreSQL backend via WebSocket/gRPC once connectivity is restored.

Here is a simplified illustration of our current local worker queue:

typescript
interface QueuedVisitorCheckIn {
  localId: string;
  visitorUid: string;
  signedBadgeToken: string; // HMAC-SHA256 signed at edge
  checkInTimestamp: number;
  syncState: 'PENDING' | 'SYNCING' | 'COMMITTED';
  retryCount: number;
}
async function flushOfflineCheckInQueue(queue: QueuedVisitorCheckIn[]): Promise<void> {
  for (const record of queue) {
    try {
      await apiClient.post('/api/v1/visitors/sync-batch', record);
      record.syncState = 'COMMITTED';
    } catch (err) {
      if (err.statusCode === 409) {
        // Handling clock-skew / concurrent check-out edge case
        handleConflictResolution(record);
      }
      break;
    }
  }
}
Where We Need Community Input

1. Conflict Resolution Strategy: If a visitor pre-registers online while an edge kiosk creates an on-the-spot walk-in record with the same phone/email during an offline partition, what CRDT or reconciliation pattern have you found most robust?

2. Offline Photo Buffering: What is the most resilient approach for handling temporary image buffers before cloud bucket sync without exhausting client disk limits on lightweight kiosk hardware?

Would love to hear how other teams handle offline queueing and eventual consistency for high-throughput front-desk check-in terminals!

Comments

[Mohammad Montazeri]

Give each queued check-in a durable, kiosk-scoped event key. The backend should commit that key and its result atomically with the visit. If it commits but the response is lost, retrying the same key should return the original result without creating another visit. That replay case needs different handling from a genuine 409 conflict.

For pre-registration/walk-in collisions, preserve both source records and treat matching phone/email as a candidate identity link, not proof they identify the same person. Reconciliation should retain the original visit and issued-token audit trail. A CRDT cannot make that identity decision; avoid silently replacing an active visit based on timestamps.

For photos, separate queue metadata from encrypted blobs, enforce a byte budget before capture, and define disk-full behavior. Delete a queued blob only after durable upload acknowledgement and confirmation that its associated record references it. Test interruption on either side of that acknowledgement; a timeout does not prove upload failure. This is a design suggestion, not a tested deployment. AI-assisted reply; I work on Lisar Connect.