Anyone who has ever been responsible for entry at a larger event knows the scenario: The line gets longer, the first guests become restless, the team at the entrance scans in sync – and just then the connection drops.

For traditional scanner setups, this is the moment when things get hectic. For us, this was exactly the starting point for the development of our scanner architecture: Entry must work, even when the internet is not functioning.

Therefore, we built our scanner app to reliably switch between online and offline operation, process tickets locally, and remain quick even under real event conditions. Not as a nice extra, but because it is simply necessary in the everyday life of events.

Why this is more than just a technical detail for organizers

Ticketing does not end with the sale. Especially on the day of the event, it becomes clear how good a platform really is. When entry, scanner access, permissions, and ticket validation work seamlessly together, the evening goes smoothly. If not, everyone notices immediately.

That’s exactly why we at Ticket AG think of ticketing not as an isolated checkout, but as an operational system. Our scanner app is part of this approach: It is designed so that organizers and door teams can remain capable of action even when network coverage, venue structure, or visitor influx are far from ideal.

What our scanner app must accomplish

The requirements are quite clear in practice:

• Scans must be processed in fractions of a second

• the system must not become unstable with fluctuating connections

• Offline scans must be synced accurately later

• multiple entrances and different permissions must be mappable

• the entry personnel need immediate understandable feedback – without having to look at the screen for long

Or to put it simply: The entry must not become an experiment.

The basic idea of our architecture

Our scanner app is based on Flutter and is designed to treat online and offline operations not as two separate worlds but as two states within the same system.

This may sound unspectacular, but it is crucial. It is precisely because of this that the app can work directly against the backend with a stable connection and immediately take over locally in the event of outages – without the team at the entrance having to change their process.

At its core, this means:

• a clearly separated architecture consisting of data, logic, and UI layers

• a local database for offline operation

• its own connectivity logic instead of blind trust in Wi-Fi symbols

• a synchronization system that brings offline scans back into the backend cleanly later

• mechanisms against double scans, false triggers, and unnecessary UI chaos

Online when it makes sense. Offline when it is necessary.

As soon as a ticket is scanned, the app checks several things in the background: Is the scanner currently busy? Is it still in cooldown? Is it a code that was already recorded recently? Only when these protective mechanisms have been passed does the actual processing start.

If a stable connection is available, the scan is sent directly to the backend. Not only the code itself is sent, but also relevant metadata – for example, event, scan type, entrance area, scanner type, device ID, and a unique trace ID for technical traceability.

If a valid response comes back, the entry personnel immediately sees the appropriate feedback: valid, already checked in, wrong entrance, not found, or other clear status messages. This eliminates any guessing at the door, allowing for a quick and understandable decision.

If the connection is not stable enough, the app skips this path entirely and processes the scan locally. The ticket is then checked directly against the local database: Is it known? Is it valid? Has it been canceled or refunded? Has it already been checked in? Is the scan type correct? Is the chosen entrance allowed?

If everything is correct, the check-in is stored locally and later synchronized. For the entry personnel, this feels just like the online mode. And that is exactly the point.

The most important difference: The team at the entrance hardly notices the switch

A good offline architecture is not recognized by its presence somewhere on a feature list. It is recognized by the fact that no chaos arises in critical moments.

Our app is built so that feedback remains consistent in both online and offline operation. This means: the same speed, the same feedback, the same clarity in handling.

Additionally, we use acoustic and haptic signals so that the team does not have to constantly look at the display. Especially with high turnover, that is not just a nice detail, but a real difference in practice.

Why connectivity is more than just "The phone shows Wi-Fi”

One of the most common misconceptions with mobile event setups is the assumption that a displayed connection automatically means that the internet is really working. Anyone who has ever dealt with overloaded venue Wi-Fi, mobile hotspots, or captive portals knows: unfortunately, no.

That’s why we don’t just rely on the pure network status of the device. Our app combines classic connectivity information with real HTTP probes to check whether a robust connection to the outside actually exists.

At the same time, debounce mechanisms prevent the entire surface from switching immediately during brief fluctuations. Because this is also important in the event context: Not every second of network flickering should lead to unrest in the system.

What happens in the background during an offline scan

When the app works offline, the scan is fully processed locally. The ticket is searched in the local database – including all known valid codes, if a ticket can have multiple scan codes.

Then the same checking logic runs, which is also relevant online:

• Is the ticket known?

• Is it still valid?

• Has it already been used?

• Does the scan match the correct category?

• Is this ticket allowed to be scanned at this entrance?

If the scan is valid, it is stored locally and marked as not yet synchronized. This is exactly the basis later for the app to smoothly hand over all offline processes to the backend during the next reconnect.

Synchronization without data chaos

Offline capability is only truly good if the way back to the central system is solved cleanly. That’s why our architecture does not rely on improvised single syncs but on a structured process.

Synchronization occurs, among other things, during a reconnect, periodically in the background, and when returning to the app. We ensure that no multiple sync processes are running simultaneously per event. Otherwise, synchronization quickly turns into confusion.

The process is designed so that:

• only the truly necessary data is reloaded

• offline scans are collected and uploaded in batches

• server responses are processed granularly

• local check-ins are not accidentally overwritten by older online data

• even large participant lists can be processed efficiently

Especially for larger events with many entries, this is crucial. Because a system that can theoretically operate offline but becomes unstable during later sync does not solve the actual problem.

Built for real event conditions, not just for demo screens

What was especially important to us during development: scanner architecture must not only look good under ideal conditions. It must function where event reality begins – with poor connectivity, high throughput, multiple entrances, spontaneous changes, and lots of pressure in the moment.

That’s why we have also included things that may seem small at first glance but are enormously important in practice:

• Cooldowns after successful scans so that the same code is not accidentally processed twice

• Duplicate buffers to quietly catch repeated recordings

• Throttled warning messages so that the UI does not drown in error messages

• Persistent device and app settings for reliable behavior across reboots

• unique trace IDs for technical traceability even during offline phases

Such mechanisms may not sound spectacular. But they are often exactly the details that determine whether an entry runs smoothly or becomes unnecessarily nervous.

Conclusion

For us, this scanner architecture is a good example of how we fundamentally understand product development. We do not build event tech for nice screenshots, but systems that must carry weight in the everyday life of organizers.

This applies to the whitelabel shop as well as to payouts, marketing tools, permissions, or backstage as a central workspace for organizers. The logic behind it is always the same: Less friction, more control, closer to the reality of the industry.

Especially during entry, this is particularly clear. Because there is no patience for half-baked processes. Either it works, or it simply does not.

The most important characteristic of a scanner app is not how modern its stack sounds at the end. The most important characteristic is that it functions reliably when it matters.

That’s exactly what our architecture is designed for: fast scanning, clean online/offline switching, robust local validation, and synchronization that remains stable even under real event conditions.

Or in one sentence: The network may fail. The entry must not.