Event Operations
Offline-first event tech: designing for the venue Wi-Fi that will fail
Venue networks fail at the worst possible moment. What has to keep working, what can degrade, and how to tell the difference before show day.
Hero art direction: Managed switch and bonded 4G router in a rack case backstage, cabling labelled, single work light. Documentary style, no people.
Assume the failure
We have never run an event where the venue network behaved exactly as promised. Sometimes it is a shared uplink saturating when an adjacent hall starts streaming. Sometimes it is a captive portal nobody mentioned. Sometimes a contractor unplugs something.
The right response is not a better SLA from the venue. It is deciding, in advance, which systems must keep working without a network at all.
Three tiers, decided before you arrive
Tier 1 — must work offline. Check-in and access control. A delegate standing at a counter cannot be told to wait for a network. Each counter holds the full delegate list locally, writes locally, and reconciles when the link returns.
Tier 2 — may degrade. The mobile app, live polls, session feedback. These should serve cached content and queue writes, not show an error screen.
Tier 3 — may stop. Public streaming, social walls, live dashboards. Losing these is visible but not operationally fatal.
Most vendor stacks put check-in in tier 3 without saying so, because a cloud-only system is cheaper to build. That is the question to ask directly.
What offline-first actually requires
- Local data, not a cache. The counter needs the whole list, on disk, queryable. A warm cache is not the same thing.
- Conflict resolution you can explain. Two counters can check in the same delegate during a partition. Decide the rule beforehand — first write wins, with the second flagged for the exception desk — and make sure staff know what the screen will say.
- Reconciliation you can watch. When the link returns, someone needs to see that 340 queued writes went up and none failed.
- A second path. Bonded 4G as an uplink, tested at the dry run rather than assumed.
Bring your own network for tier 1
For registration and access control we bring our own segmented network: managed switching, our own SSIDs, our own DHCP, and the venue link treated as an uplink rather than as infrastructure. It costs more than using venue Wi-Fi. It also means a venue problem is not our problem.
Test the failure, not the feature
The dry run should include pulling the uplink while a check-in is mid-transaction. Every event we run does this, and it finds something roughly one time in three — usually a screen that spins rather than telling staff what to do.
A supplier who has not tested their own failure path will discover it in front of your delegates.
Questions we get
Follow-ups
01Is bringing your own network really necessary?
For registration and access control, yes. For everything else, usually not. The cost is a few thousand rupees of switching and a bonded 4G line against the cost of a stalled entrance, which is the one failure your delegates will remember.
02What happens to data collected while offline?
It is written locally and queued, then reconciled when the link returns. The control room sees the queue depth and the reconciliation result, so nobody has to trust that it worked. Nothing is discarded.
03How do you handle two counters checking in the same delegate?
First write wins; the second is flagged to the exception desk with both timestamps. Staff are briefed on exactly what that screen says before doors open, because the technical rule only matters if the person reading it knows what to do.
Talk to the team that runs this on the floor
Send the date, the city and the headcount. We reply with numbers.
Further reading
Was this useful?