Hi all,
We are currently architecting the client-server pipeline for an enterprise visitor management system designed for corporate campuses and multi-tenant commercial facilities.
During morning peak hours, reception kiosks experience burst check-ins (simultaneous QR badge scanning, photo capture, and thermal badge printer triggers).
The Challenge
Network Resilience: If the facility experiences a brief WAN outage, kiosks must continue operating locally in an offline-first state, buffering check-in records in local storage/SQLite, and reconciling state
with the central cloud database upon reconnection without race conditions.Real-time Host Notification: When a visitor checks in, the host employee needs instant notification via Webhooks / Slack / SMS, and the badge printer needs immediate dispatch.
Current High-Level Stack:
- Kiosk Frontend: Electron / React on touch tablets
- Edge Layer: Local MQTT broker on a gateway node or persistent WebSocket connections direct to backend
- Backend: Node.js microservices + Redis Pub/Sub + PostgreSQL
Where We’d Love Community Input:
For those who have built offline-first edge kiosk solutions, do you prefer MQTT with local broker persistence or WebSocket connections with client-side IndexedDB/SQLite queues?
How do you handle clock drift and audit log sequencing when offline-buffered check-ins sync back out-of-order?
Looking forward to hearing how others have approached similar access and check-in architectures!
Top comments (0)