Ticket-Buchungssystem-Design

Architektur von Ticketbuchungssystemen: Von APIs bis zur Skalierbarkeit

Ein Ticketbuchungssystem muss das Durchsuchen von Veranstaltungen, die parameterbasierte Suche und zuverlässige Reservierungen ohne Doppelverkäufe unterstützen. Der Fokus liegt auf Datenverfügbarkeit für Lesevorgänge und strenger Konsistenz für Schreibvorgänge. Erwartete Last – bis zu 10 Millionen Nutzer für eine beliebte Veranstaltung, Suchlatenz unter 500 ms, Lese-zu-Schreib-Verhältnis von 100:1.

Wichtige Entitäten: Veranstaltung (mit Datum, Beschreibung, Typ), Nutzer, Künstler, Veranstaltungsort (mit Sitzplan), Ticket (mit Sitz, Preis, Status), Buchung (mit Ticketliste und Status).

API-Endpoints entwerfen

Die API wird um drei Prioritätsfunktionen herum aufgebaut. Beginnen Sie mit einfachen Endpoints und verfeinern Sie diese im Laufe des Designs.

Veranstaltung anzeigen:

GET /events/:id -> Event & Venue & Performer & Ticket[]

Gibt Veranstaltungsdetails, Veranstaltungsort, Künstler und Ticketliste für die Darstellung des Sitzplans auf dem Client zurück.

Suche:

GET /events/search?keyword={keyword}&start={start_date}&end={end_date}&pageSize={page_size}&page={page_number} -> Event[]

Filter nach Stichwörtern, Datumsangaben, Paginierung für hohen Durchsatz.

Buchung (erste Version):

POST /bookings/:eventId -> bookingId
{
  "ticketIds": string[],
  "paymentDetails": ...
}

Später in Reservierung und Bestätigung für transaktionale Zuverlässigkeit aufteilen.

High-Level-Architektur

Systemkomponenten

• API-Gateway: Routing, Authentifizierung, Ratenbegrenzung, Protokollierung.
• Event-Service: Lesen von Veranstaltungs-, Veranstaltungsort- und Künstlerdaten aus der DB.
• Such-Service: Verarbeitung von Suchanfragen mit Filterung.
• Buchungs-Service: Verwaltung von Reservierungen mit Transaktionen.
• Datenbanken: PostgreSQL für ACID-Transaktionen (Buchungen, Tickets), NoSQL oder Cache für Lesevorgänge (Veranstaltungen, Veranstaltungsorte).

Ansichtsablauf: Client → Gateway → Event-Service → DB → Antwort mit Sitzplan.

Skalierung unter Last

Für 10 Millionen DAU pro Veranstaltung verwenden:

• Caching: Redis für häufige Lesevorgänge (Veranstaltungen, Suche).
• Sharding: nach eventId in Tickets/Buchungen.
• CQRS: Trennung von Lesevorgängen (Read Replicas) und Schreibvorgängen (Master).
• Load Balancer: Verteilung des Datenverkehrs über Dienste.

Das 100:1 Lese-/Schreib-Verhältnis diktiert Priorität auf Read Replicas und CDN für statische Daten (Sitzpläne).

Buchungsdetails und Konsistenz

Kritischer Bereich – Vermeidung von Doppelbuchungen. PostgreSQL mit Transaktionen und Serializable-Isolation oder Optimistic Concurrency Control (OCC) auf Ticketversionen.

Prozess:

• Client wählt ticketIds aus.
• Buchungs-Service startet Transaktion: SELECT FOR UPDATE auf Tickets.
• Status prüfen (verfügbar), auf reserviert aktualisieren.
• Buchungsdatensatz erstellen.
• Zahlungsbestätigung → Status bestätigt.

Beispiel Tickets-Tabelle:

| id | event_id | section | row | seat | price | status | version |

|----|----------|---------|-----|------|-------|--------|---------|

| 1 | 123 | A | 1 | 5 | 100 | available | 1 |

OCC: bei UPDATE Version prüfen, bei Konflikt ablehnen.

Für hohe Parallelität – temporäre Reservierungen (TTL 10 Min) in Redis.

Suchoptimierung

Grundlegende SQL-Filterung skaliert nicht auf 10 Millionen. Übergang zu:

• Elasticsearch für Volltextsuche nach Stichwort, Künstler, Veranstaltungsort.
• Indizierung von Veranstaltungen mit Feldern: Name, Datumsbereich, Ort.
• Facettierte Suche für Filter (Datum, Typ).

Ablauf: Such-Service → ES-Abfrage → Aggregation → Cache in Redis.

Latenz <500 ms durch Vorladen beliebter Veranstaltungen erreicht.

Tiefere Einblicke in Skalierbarkeit

Datenbanken

• Master PostgreSQL (Buchungen, Tickets) – nach eventId gesharded.
• Read Replicas – 10+ für Veranstaltungsansicht.
• Redis – Sitzungen, temporäre Reservierungen, Top-Veranstaltungen.
• Elasticsearch – Suche, Analysen.

Datenmigration: Event-Service schreibt in Kafka → CDC → Replicas/ES.

Überwachung und Fehlertoleranz

• Circuit Breakers in Diensten.
• Health Checks, automatische Skalierung.
• Backups: WAL-Archivierung in S3.

Wichtige Erkenntnisse

• Strenge Konsistenz nur in Buchungstransaktionen, Eventual Consistency für die Suche.
• OCC + temporäre Sperren in Redis verhindern 99% der Konflikte ohne Blockierung.
• CQRS/ES gewährleisten <500 ms Suche unter 100:1 Last.
• Sharding nach eventId skaliert auf 10M+ DAU.
• API-Gateway zentralisiert Sicherheit und Drosselung.

— Editorial Team