QR-Ticket-Validierungsdesign für Kinos

QR-Ticket-Validierungssystemdesign: Von Offline zu Idempotenz

Ein Ticketkontrolleur scannt einen QR-Code, das System prüft ihn in der Datenbank und markiert ihn als verwendet. Die Kernanforderung: Ein Ticket, ein Eintritt. Eine scheinbar einfache Aufgabe wird durch Netzwerkausfälle, Warteschlangen und mehrere Kontrolleure kompliziert. Lassen Sie uns die Entwicklung der Lösungen von der Offline-Validierung zur zuverlässigen serverseitigen Verarbeitung erkunden.

Der Offline-Modus verwendet eine digitale Signatur (ECC oder RSA). Der QR-Code enthält die Ticketdaten und Signatur; der Kontrolleur überprüft sie mit einem öffentlichen Schlüssel ohne Netzwerkverbindung. Das Problem: Fehlende Synchronisation zwischen Kontrolleuren. Ein Screenshot des Tickets kann an jedem Eingang unabhängig verwendet werden.

Serverseitiger Status und atomare Updates

Ein zentralisiertes Speichersystem löst das Synchronisationsproblem. Jeder Scan ist eine Anfrage an den Server mit einem atomaren Statusupdate.

Beispiel in PostgreSQL:

UPDATE tickets 
SET status = 'used', used_at = NOW()
WHERE id = :ticket_id AND status = 'active'
RETURNING *;

Wenn eine Zeile zurückgegeben wird, ist das Ticket eingelöst und der Eintritt gewährt. Wenn keine Zeile zurückgegeben wird, ist das Ticket bereits verwendet oder existiert nicht.

Ein klassisches Problem: Verlust der Serverantwort. Ein Kontrolleur in einem Gebiet mit schlechtem Signal sendet eine Anfrage, der Server aktualisiert die Datenbank, aber die Antwort kommt nicht an. Ein Timeout tritt auf, ein erneuter Scan wird versucht – der Server lehnt ab, und der Kunde kann trotz bezahltem Ticket nicht eintreten.

Idempotenz auf API-Ebene

Die Lösung sind idempotente Anfragen mit einem eindeutigen Schlüssel (UUID), der beim Öffnen einer Scan-Sitzung generiert wird. Der Schlüssel zeichnet den Versuch auf, sodass Wiederholungen ohne Duplizierung möglich sind.

Logik innerhalb einer Transaktion (read committed):

begin ;

-- 1. Versuch aufzeichnen
INSERT INTO processed_requests (ticket_id, idempotency_key)
VALUES (:ticket_id, :idempotency_key)
ON CONFLICT (ticket_id, idempotency_key) 
DO NOTHING RETURNING *;

-- 2. Wenn rows_affected == 0: rollback, return SUCCESS

-- 3. Ticket einlösen
UPDATE tickets 
SET status = 'used', used_at = NOW()
WHERE id = :ticket_id AND status = 'active'
RETURNING *;

-- 4. Wenn rows_affected == 0: rollback, return ERROR

commit;
-- 5. Return SUCCESS

Die Transaktion gewährleistet Atomarität: Entweder werden Schlüssel und Status aktualisiert oder nichts. Ein eindeutiger Index auf (ticket_id, idempotency_key) verhindert Race Conditions – die zweite Anfrage wartet oder geht zu DO NOTHING.

Ein Wiederholungsversuch innerhalb derselben Sitzung gibt Erfolg zurück, selbst wenn die erste Antwort verloren ging.

Head-of-Line-Blocking und Kontextverlust

Ein echtes Problem: Ein Kontrolleur unter Druck einer Warteschlange schließt die Sitzung ohne Antwort. Ein neuer Scan generiert einen frischen idempotency_key. Der Server sieht ein verwendetes Ticket mit einem anderen Schlüssel – Ablehnung.

Der Kontrolleur kann einen legitimen Kunden nicht von einem Betrüger mit einem Screenshot unterscheiden. Head-of-Line-Blocking erfordert eine endgültige Antwort vor dem nächsten Ticket.

Ein Kompromiss: Rückgabe des Zeitstempels der letzten Verwendung. Der Kontrolleur bewertet: „Vor 2 Minuten – wahrscheinlich dieselbe Person.“ Risiko: Eine Gruppe mit einem geteilten QR-Code passiert nacheinander.

Schlüsselherausforderungen:

• Netzwerk-Timeouts ohne Statusverlust
• Synchronisation mehrerer Kontrolleure
• Menschliche Faktoren in Warteschlangen
• Abwägung von Zuverlässigkeit und UX

Wichtige Erkenntnisse

• Atomares UPDATE mit Bedingung status='active' verhindert doppelte Einlösung
• Idempotenz via UUID + eindeutiger Index garantiert Wiederholungen ohne Duplikate
• Transaktionen (read committed) gewährleisten sequenzielle Sichtbarkeit von Änderungen
• Head-of-Line-Blocking ist für 100% Zuverlässigkeit ohne Biometrie unvermeidlich
• Der Zeitstempel-Kompromiss verlagert die Entscheidung auf den Bediener

Zukünftige Verbesserungen

Statische QR-Codes werden veraltet. Dynamische Token oder Challenge-Response mit Einmal-OTPs lösen das Problem. Der Kontrolleur fordert einen Nonce vom Server an, der Kunde signiert ihn – der Server überprüft und markiert ihn atomar.

Biometrie (Face ID) oder NFC eliminieren Screenshots, erfordern aber Hardware. QUIC minimiert Paketverlust, löst aber Kontextverlust nicht.

Skalierung: Redis zum Caching von idempotency_keys, Sharding nach ticket_id. Monitoring: Metriken für fehlgeschlagene Scans nach Zeitstempel, A/B-Tests von Kompromissen.

— Editorial Team