Designing an offline-first kiosk architecture for high-concurrency visitor check-ins: WebSockets vs MQTT?

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!