You are standing at the entrance of a 500-person conference. The venue promised strong WiFi, but 400 guests just walked through the door and the network buckled. Your scanning app shows a spinner. The line is backing up past the coat check.
Or maybe it is an outdoor festival and there was never a reliable signal to begin with. Or a fundraiser in a concrete basement where your phone shows one bar of LTE on a good day.
If you have already read how QR ticket scanning works in Melda, you know the basics: one QR code per guest, PIN-protected browser scanner, instant visual feedback. This article is about what happens when the internet disappears.
Will it be fast enough at the door?
When the scanner opens, it downloads the full ticket manifest and caches it on the device. It then builds an indexed lookup map from that data.
Every scan is validated locally against this index. No server call. The lookup is O(1) — same speed at 50 tickets or 6,000. The result appears in under a millisecond.
The manifest is persisted to localStorage, so if the browser is closed and reopened, the data is still there. While the device is online, the manifest quietly refreshes every 30 seconds in the background — so new RSVPs and cancellations flow through without anyone lifting a finger.
What if the browser crashes or the phone dies?
Every check-in is written to a localStorage queue before the green flash appears on screen. The write happens first, then the visual confirmation. This ordering is deliberate.
If the browser crashes mid-scan, the check-in is already in the queue. If the phone restarts, the queue survives. If someone accidentally closes the tab and reopens it five minutes later, every pending check-in is still there.
Data loss from a crash is not an edge case we mitigate. It is architecturally impossible. The queue is the source of truth until the server acknowledges the sync.
When does the server find out?
Three mechanisms ensure check-ins reach the server.
Reconnection sync. The moment the device comes back online, the scanner waits 500 milliseconds for the connection to stabilize, then sends all pending check-ins in a single batch request.
Background interval. A timer runs every 10 seconds. If there are pending check-ins at least 2 seconds old and the device is online, it sends them. This catches anything the reconnection event missed.
Pending count on screen. The scanner shows a visible count of unsynced check-ins. Zero means the server has confirmed everything.
What happens when...
"What if two offline devices scan the same person?" Both devices show green and record the scan. The guest is checked in once; the audit log may retain both entries for traceability. If either device is already online, the second device flashes amber with the original check-in time.
"What if a guest cancels after the manifest was cached?" A guest who cancels while devices are offline will still scan green in the cached manifest. We chose this deliberately: blocking a legitimate guest because the cache is a few minutes stale is worse than turning a real guest away over a stale cache. Every device refreshes its manifest every 30 seconds while online, so cancelled tickets disappear the moment connectivity returns.
"How do I know check-ins actually synced?" The pending count on the scanner screen. Zero means confirmed. The event dashboard also shows a timestamped log of every check-in from every device.
How to verify it works before your event
Run this test with your client on the line — it takes ninety seconds and closes every "what if" before the event.
- Open the scanner and enter the PIN. Wait until the guest list has finished loading before continuing — you will see the list populate.
- Put your phone in airplane mode.
- Scan a test ticket. Green flash, pending count goes to 1.
- Turn off airplane mode. Within a second or two the pending count drops to 0.
That is the entire offline architecture in action: recorded locally, queued, and synced.
Credits and bar mode
The same offline architecture extends to credits and drink tickets. If your event has a bar with fixed drink allocations or flexible credits, the bartender scans the guest's QR code to redeem a credit. The transaction is queued and synced exactly like a check-in. The full credits system is a separate article.
Every scan is saved locally first — the cloud catches up when it can.
Want to see it in action with your own event? Create an event in under 2 minutes →
Real scenarios
An outdoor festival for 2,000 guests. Cell signal is nonexistent behind the stage tent. Three gates, three phones, all offline since loading the manifest before doors opened. Guests flow through, check-ins stack up in local queues. When the portable hotspot kicks in an hour later, hundreds of check-ins sync in a single batch.
A tech conference in a concrete basement. WiFi password does not work. Mobile signal dies in the stone walls. You check in 300 attendees over two hours with zero internet, the pending count ticking up in the corner of the screen. When you carry your phone upstairs for coffee, the queue drains automatically. By the time you are back downstairs, the server has every check-in.
If you are already using QR ticket scanning in Melda, offline mode is built in — there is nothing extra to enable. And if you are planning your first event, start here. The scanner is included with every Melda event.