Jede Person, die schon einmal den Einlass bei einem größeren Event verantwortet hat, kennt das Szenario: Die Schlange wird länger, die ersten Gäste werden unruhig, das Team am Eingang scannt im Takt – und genau dann bricht die Verbindung weg.

Für klassische Scanner-Setups ist das der Moment, in dem es hektisch wird. Für uns war genau das der Ausgangspunkt bei der Entwicklung unserer Scanner-Architektur: Einlass muss funktionieren, auch wenn das Internet es gerade nicht tut.

Deshalb haben wir unsere Scanner-App so gebaut, dass sie zuverlässig zwischen Online- und Offline-Betrieb wechselt, Tickets lokal verarbeiten kann und auch unter realen Eventbedingungen schnell bleibt. Nicht als nettes Extra, sondern weil es im Veranstaltungsalltag schlicht notwendig ist.

Warum das für Veranstalter mehr ist als ein technisches Detail

Ticketing endet nicht beim Verkauf. Gerade am Veranstaltungstag zeigt sich, wie gut eine Plattform wirklich ist. Wenn Einlass, Scanner-Zugänge, Berechtigungen und Ticketvalidierung sauber zusammenspielen, läuft der Abend. Wenn nicht, merkt es jeder sofort.

Genau deshalb denken wir Ticketing bei Ticket AG nicht als isolierten Checkout, sondern als operatives System. Unsere Scanner-App ist Teil dieses Ansatzes: Sie ist dafür gebaut, dass Veranstalter und Türteams auch dann handlungsfähig bleiben, wenn Netzabdeckung, Venue-Struktur oder Besucherandrang alles andere als ideal sind.

Was unsere Scanner-App leisten muss

Die Anforderungen sind in der Praxis ziemlich klar:

• Scans müssen in Sekundenbruchteilen verarbeitet werden

• das System darf bei schwankender Verbindung nicht instabil werden

• Offline-Scans müssen später sauber synchronisiert werden

• mehrere Eingänge und unterschiedliche Berechtigungen müssen abbildbar sein

• das Einlasspersonal braucht sofort verständliches Feedback – ohne lange auf den Bildschirm schauen zu müssen

Oder einfacher gesagt: Der Einlass darf nicht zum Experiment werden.

Die Grundidee unserer Architektur

Unsere Scanner-App basiert auf Flutter und ist so aufgebaut, dass sie Online- und Offline-Betrieb nicht als zwei getrennte Welten behandelt, sondern als zwei Zustände innerhalb desselben Systems.

Das klingt unspektakulär, ist aber entscheidend. Denn genau dadurch kann die App bei einer stabilen Verbindung direkt gegen das Backend arbeiten und bei Ausfällen sofort lokal übernehmen – ohne dass das Team am Einlass seinen Ablauf ändern muss.

Im Kern bedeutet das:

• eine klar getrennte Architektur aus Daten-, Logik- und UI-Schicht

• eine lokale Datenbank für den Offline-Betrieb

• eine eigene Konnektivitätslogik statt blindem Vertrauen auf WLAN-Symbole

• ein Synchronisationssystem, das Offline-Scans später sauber zurück ins Backend bringt

• Mechanismen gegen Doppel-Scans, Fehltrigger und unnötige UI-Unruhe

Online, wenn es sinnvoll ist. Offline, wenn es nötig ist.

Sobald ein Ticket gescannt wird, prüft die App im Hintergrund mehrere Dinge: Ist der Scanner gerade beschäftigt? Befindet er sich noch im Cooldown? Handelt es sich um einen kürzlich bereits erfassten Code? Erst wenn diese Schutzmechanismen passiert sind, startet die eigentliche Verarbeitung.

Wenn eine stabile Verbindung vorhanden ist, wird der Scan direkt an das Backend gesendet. Dabei werden nicht nur der Code selbst, sondern auch relevante Metadaten mitgeschickt – zum Beispiel Event, Scan-Typ, Eingangsbereich, Scanner-Art, Geräte-ID und eine eindeutige Trace-ID für die technische Nachvollziehbarkeit.

Kommt eine gültige Antwort zurück, sieht das Einlasspersonal sofort das passende Feedback: gültig, bereits eingecheckt, falscher Eingang, nicht gefunden oder andere klare Statusmeldungen. So entsteht kein Rätselraten an der Tür, sondern eine schnelle und nachvollziehbare Entscheidung.

Wenn die Verbindung aber nicht stabil genug ist, überspringt die App diesen Weg komplett und verarbeitet den Scan lokal. Das Ticket wird dann direkt gegen den lokalen Datenbestand geprüft: Ist es bekannt? Ist es gültig? Wurde es storniert oder erstattet? Wurde es bereits eingecheckt? Passt der Scan-Typ? Ist der gewählte Eingangsbereich zulässig?

Wenn alles passt, wird der Check-in lokal gespeichert und später synchronisiert. Für das Einlasspersonal fühlt sich das genauso an wie im Online-Modus. Und genau darum geht es.

Der wichtigste Unterschied: Das Team am Einlass merkt vom Umschalten fast nichts

Eine gute Offline-Architektur erkennt man nicht daran, dass sie irgendwo in einer Feature-Liste auftaucht. Man erkennt sie daran, dass in kritischen Momenten kein Chaos entsteht.

Unsere App ist so gebaut, dass das Feedback im Online- und Offline-Betrieb konsistent bleibt. Das heißt: gleiche Geschwindigkeit, gleiche Rückmeldung, gleiche Klarheit im Handling.

Zusätzlich nutzen wir akustische und haptische Signale, damit das Team nicht permanent auf das Display schauen muss. Gerade bei hohem Durchlauf ist das kein nettes Detail, sondern ein echter Unterschied in der Praxis.

Warum Konnektivität mehr ist als „Das Handy zeigt doch WLAN an“

Einer der häufigsten Trugschlüsse bei mobilen Event-Setups ist die Annahme, dass eine angezeigte Verbindung automatisch bedeutet, dass das Internet wirklich funktioniert. Wer schon einmal mit überlastetem Venue-WLAN, mobilen Hotspots oder Captive Portals gearbeitet hat, weiß: leider nein.

Deshalb verlassen wir uns nicht nur auf den reinen Netzwerkstatus des Geräts. Unsere App kombiniert klassische Konnektivitätsinformationen mit echten HTTP-Probes, um zu prüfen, ob tatsächlich eine belastbare Verbindung nach außen besteht.

Gleichzeitig verhindern Debounce-Mechanismen, dass bei kurzen Schwankungen sofort die komplette Oberfläche umspringt. Denn auch das ist im Eventkontext wichtig: Nicht jede Sekunde Netzflackern darf direkt zu Unruhe im System führen.

Was bei einem Offline-Scan im Hintergrund passiert

Wenn die App offline arbeitet, wird der Scan vollständig lokal verarbeitet. Das Ticket wird in der lokalen Datenbank gesucht – inklusive aller bekannten gültigen Codes, falls ein Ticket mehrere Scan-Codes besitzen kann.

Danach läuft dieselbe Prüflogik, die auch online relevant ist:

• Ist das Ticket bekannt?

• Ist es noch gültig?

• Wurde es bereits verwendet?

• Passt der Scan zur richtigen Kategorie?

• Darf dieses Ticket an genau diesem Eingang gescannt werden?

Wenn der Scan gültig ist, wird er lokal gespeichert und als noch nicht synchronisiert markiert. Genau das ist später die Grundlage dafür, dass die App beim nächsten Reconnect alle Offline-Vorgänge sauber an das Backend übergeben kann.

Synchronisation ohne Datenchaos

Offline-Fähigkeit ist nur dann wirklich gut, wenn der Weg zurück ins zentrale System sauber gelöst ist. Deshalb setzt unsere Architektur nicht auf improvisierte Einzelsyncs, sondern auf einen strukturierten Prozess.

Synchronisiert wird unter anderem bei einem Reconnect, periodisch im Hintergrund und beim Zurückkehren in die App. Dabei achten wir darauf, dass pro Event nicht mehrere Sync-Prozesse gleichzeitig laufen. Sonst wird aus Synchronisation sehr schnell Verwirrung.

Der Ablauf ist so konzipiert, dass:

• nur die wirklich nötigen Daten nachgeladen werden

• Offline-Scans gesammelt und gebündelt hochgeladen werden

• Server-Antworten granular verarbeitet werden

• lokale Check-ins nicht versehentlich von älteren Online-Daten überschrieben werden

• auch große Teilnehmerlisten performant verarbeitet werden können

Gerade bei größeren Events mit vielen Einträgen ist das entscheidend. Denn ein System, das theoretisch offline kann, aber beim späteren Sync instabil wird, löst das eigentliche Problem nicht.

Gebaut für echte Eventbedingungen, nicht nur für Demo-Screens

Was uns bei der Entwicklung besonders wichtig war: Scanner-Architektur darf nicht nur unter Idealbedingungen gut aussehen. Sie muss dort funktionieren, wo Eventrealität anfängt – bei schlechter Verbindung, hohem Durchsatz, mehreren Eingängen, spontanen Änderungen und jeder Menge Druck im Moment.

Deshalb haben wir auch Dinge eingebaut, die auf den ersten Blick klein wirken, in der Praxis aber enorm wichtig sind:

• Cooldowns nach erfolgreichen Scans, damit derselbe Code nicht versehentlich doppelt verarbeitet wird

• Duplikat-Buffer, um wiederholte Erfassungen still abzufangen

• gedrosselte Warnhinweise, damit das UI nicht in Fehlermeldungen untergeht

• persistente Geräte- und App-Einstellungen für verlässliches Verhalten über Neustarts hinweg

• eindeutige Trace-IDs für technische Nachvollziehbarkeit auch über Offline-Phasen hinweg

Solche Mechanismen klingen nicht spektakulär. Sie sind aber oft genau die Details, die darüber entscheiden, ob ein Einlass souverän läuft oder unnötig nervös wird.

Fazit

Für uns ist diese Scanner-Architektur ein gutes Beispiel dafür, wie wir Produktentwicklung grundsätzlich verstehen. Wir bauen keine Event-Tech für schöne Screenshots, sondern Systeme, die im Alltag von Veranstaltern tragen müssen.

Das gilt für den Whitelabel-Shop genauso wie für Auszahlungen, Marketing-Tools, Berechtigungen oder Backstage als zentrale Arbeitsoberfläche für Veranstalter. Die Logik dahinter ist immer dieselbe: Weniger Reibung, mehr Kontrolle, näher an der Realität der Branche.

Gerade beim Einlass zeigt sich das besonders klar. Denn dort gibt es keine Geduld für halbgare Prozesse. Entweder es läuft, oder es läuft eben nicht.

Die wichtigste Eigenschaft einer Scanner-App ist am Ende nicht, wie modern ihr Stack klingt. Die wichtigste Eigenschaft ist, dass sie dann zuverlässig funktioniert, wenn es darauf ankommt.

Genau darauf ist unsere Architektur ausgelegt: schnelles Scannen, saubere Online-/Offline-Wechsel, belastbare lokale Validierung und eine Synchronisation, die auch unter realen Eventbedingungen stabil bleibt.

Oder in einem Satz: Das Netz darf ausfallen. Der Einlass nicht.