Skalierbares Reservierungssystem für Konzerttickets — Entwurfsplan

1. Annahmen

• Einzelne Cloud-Region (z. B. AWS us-east-1) mit 3 AZs; verwaltete Dienste bevorzugt.
• Der Katalog (Events, Veranstaltungsorte, Sitzpläne) ist leselastig und ändert sich selten.
• Reservierungen sind der Hot Path; Zahlungen laufen über asynchrone Callbacks außerhalb des Hot Path.
• „Niemals überverkaufen" ist eine harte Invariante; kurzzeitige Nichtverfügbarkeit wird einem Doppelverkauf vorgezogen.
• Ein externer Zahlungsanbieter (z. B. Stripe/Adyen) übernimmt den PCI-Umfang; wir speichern nur Tokens.
• Durchschnittliche Eventgröße 30k Sitze; Spitzenlast dauert Minuten bis ~1 Stunde.

2. Architektur auf hoher Ebene

Clients (Web/Mobile) → CDN (CloudFront) → API Gateway / L7 Load Balancer → Edge-Auth (JWT) → Zustandslose Microservices auf Kubernetes (EKS) über 3 AZs.

Kerndienste:

• Identity Service: Registrierung, Login, JWT-Ausgabe, MFA.
• Catalog Service: Events, Veranstaltungsorte, Sitzplan-Metadaten; leseoptimiert.
• Inventory/Seat Service: autoritativer Sitzzustand, Holds, Reservierungen; der Konsistenzanker.
• Reservation Service: orchestriert Hold → Checkout → Payment Intent.
• Payment Service: integriert den Anbieter, verarbeitet Webhook-Callbacks idempotent.
• Ticket Service: gibt signierte digitale Tickets (JWT/QR) nach erfolgreicher Zahlung aus.
• Notification Service: E-Mail/Push (SES/SNS).
• Waiting Room / Virtual Queue Service: drosselt den Zutritt während Verkaufsspitzen.
• Expiration Worker: gibt unbezahlte Holds nach 10 Minuten frei.
• Admin/Onsale Service: Event-Konfiguration, Sitzplan-Upload, Verkaufsplanung.

Querschnittsthemen: Kafka (MSK) für Events, Redis (ElastiCache, Cluster-Modus) für Hot State und Locks, PostgreSQL (Aurora Multi-AZ) für transaktionale Daten, DynamoDB für Idempotenzschlüssel und Ticket-Store, S3 für Sitzplan-JSON/-Bilder, OpenSearch für die Event-Suche.

3. Datenspeicher

• Aurora PostgreSQL (Multi-AZ, 1 Writer + 2 Reader): Events, Nutzer, Reservierungen, Zahlungen, Tickets (System of Record). Kontinuierliches Backup; PITR.
• Redis Cluster (Multi-AZ, mit Replicas): Hold-Zustand pro Sitz, Sitz-Bitmap-Cache pro Event, Rate Limits, Waiting-Room-Tokens. Wird für schnelles CAS auf Holds verwendet.
• DynamoDB: Zahlungs-Idempotenzschlüssel, Webhook-Deduplizierung, Lookup ausgestellter Tickets (niedrige Latenz, standardmäßig Multi-AZ).
• Kafka (MSK): Domain-Events (SeatHeld, ReservationCreated, PaymentSucceeded, PaymentFailed, ReservationExpired, TicketIssued). Replikationsfaktor 3 über AZs hinweg.
• S3: statische Sitzplan-Artefakte, Ticket-PDFs.
• CDN: cacht Event-Listen, Sitzplan-Skelett (nicht die Live-Verfügbarkeit).
• OpenSearch: Event-Suche/-Filterung.

4. Kern-Datenmodell

events(event_id PK, venue_id, name, onsale_at, status, version).
seats(seat_id PK, event_id, section, row, number, price_tier, status ENUM[available, held, reserved, sold], hold_id NULL, version BIGINT). Zusammengesetzter Index (event_id, status). Zeilenversionierung für optimistisches Sperren.
reservations(reservation_id PK, user_id, event_id, seat_ids[], state ENUM[pending_payment, confirmed, expired, cancelled], created_at, expires_at, payment_intent_id, idempotency_key UNIQUE).
payments(payment_id PK, reservation_id, provider_ref UNIQUE, status, amount, currency, received_at). Unique-Constraint auf provider_ref für At-least-once-Deduplizierung.
tickets(ticket_id PK, reservation_id, seat_id, qr_payload, issued_at, signature).
outbox(id, aggregate, payload, published_at) für das transaktionale Outbox-Muster → Kafka.

Redis-Schlüssel:

• event:{id}:seat:{seat_id} → Status + Hold-Eigentümer + TTL 600s.
• event:{id}:availability → Bitmap/HLL für schnelle Zählungen.
• hold:{reservation_id} → Sitzliste, TTL 600s.

5. Kern-APIs (REST + Idempotenz-Header)

• GET /events?filters → paginierte Liste (CDN-cachefähig, 30s TTL).
• GET /events/{id} → Event-Details.
• GET /events/{id}/seatmap → statisches Layout (langes Caching).
• GET /events/{id}/availability → grobe Verfügbarkeit (Sektionen); 1–5s Cache.
• GET /events/{id}/seats?section=A → feingranularer Sitzstatus (kurzes Caching oder live).
• POST /reservations (Idempotency-Key) → {event_id, seat_ids[]} → erstellt 10-minütigen Hold.
• GET /reservations/{id} → Zustand, expires_at.
• DELETE /reservations/{id} → Nutzer storniert, gibt Sitze frei.
• POST /reservations/{id}/checkout → erstellt Payment Intent beim Anbieter, gibt Client Secret zurück.
• POST /webhooks/payments → Anbieter-Callback (signiert, idempotent).
• GET /tickets/{id} → signiertes digitales Ticket.
• Admin: POST /events, POST /events/{id}/seats:bulk, POST /events/{id}/onsale.

6. Request-Abläufe

Browsing

Client → CDN (Treffer für Katalog/Sitzplan) → bei Miss, API → Catalog Service → Aurora Reader / OpenSearch. Verfügbarkeitszählungen werden aus Redis mit 1–5s Veralterung ausgeliefert; einzelne Sitzzustände werden live für die Sektion abgerufen, die der Nutzer gerade betrachtet.

Reservierung (Hold)

1. Der Client sendet POST /reservations mit Idempotency-Key und Zielsitzen.
2. Das API Gateway prüft das Waiting-Room-Token; Rate-Limitierung pro Nutzer/IP.
3. Der Reservation Service validiert Event-Status und Sitz-IDs.
4. Holds atomar erwerben per Redis-Lua-Skript: für jeden Sitzschlüssel SETNX mit hold_id und TTL 600s; schlägt ein Sitz fehl, werden die erfolgreichen zurückgerollt und ein 409 mit den kollidierenden Sitzen zurückgegeben.
5. Reservierungszeile in Aurora im Zustand pending_payment persistieren (einzelne Transaktion mit Outbox-Event). Optimistisches Sperren auf Sitzen verwenden: UPDATE seats SET status='held', hold_id=?, version=version+1 WHERE seat_id=? AND status='available'. Aurora ist die dauerhafte Wahrheit; Redis ist der schnelle Wächter. Beide müssen übereinstimmen.
6. Reservierung mit expires_at zurückgeben. p95 < 800 ms.

Zahlung

1. Der Client ruft POST /reservations/{id}/checkout auf; der Payment Service erstellt einen PaymentIntent beim Anbieter und speichert provider_ref mit reservation_id als Schlüssel (idempotent).
2. Der Client schließt die Zahlung direkt über das Anbieter-SDK ab (wir bleiben außerhalb des PCI-Umfangs).
3. Der Anbieter sendet einen Webhook → POST /webhooks/payments.
4. Webhook-Handler: Signatur verifizieren → Upsert in payments unter Verwendung von provider_ref UNIQUE (Deduplizierung). DynamoDB-Conditional-Put auf event_id für zusätzliche Idempotenz verwenden.
5. Bei succeeded: transaktionales Update — reservation→confirmed, seats→sold, tickets schreiben, Outbox-Event TicketIssued anhängen. Sicherheit bei falscher Reihenfolge: Der Handler vergleicht Event-Zeitstempel und ignoriert veraltete Übergänge (Zustandsautomat: pending → confirmed/failed/expired, terminale Zustände absorbieren späte Duplikate).
6. Der Ticket Service konsumiert TicketIssued, generiert signierten QR/PDF, speichert in S3 + DynamoDB; der Notification Service benachrichtigt den Nutzer per E-Mail.

Ablauf (Expiration)

• Primär: Redis-TTL lässt den hold:*-Schlüssel ablaufen → eine Keyspace-Notification löst den Expiration Worker aus; der Worker führt eine Aurora-Transaktion aus, die Sitze nur freigibt, wenn die Reservierung noch pending_payment ist (CAS auf state).
• Absicherung: ein geplanter Job scannt alle 30s reservations WHERE state='pending_payment' AND expires_at < now() - 30s und gibt frei. Spät eintreffender Webhook nach Ablauf: Ist der Sitz bereits weiterverkauft, wird die Zahlung als refund_required markiert und eine automatische Rückerstattung ausgelöst; ist der Sitz noch frei, kann optional erneut bestätigt werden — die Standardrichtlinie ist jedoch Rückerstattung, da wir einen möglicherweise weiterverkauften Sitz nicht erneut halten können. Die 5-Minuten-Verzögerung des Zahlungsanbieters liegt innerhalb des 10-minütigen Hold-Fensters, sodass im Normalfall kein Konflikt entsteht.

7. Verhinderung von Überverkäufen (Konsistenz)

• Ein Sitz ist eine einzelne besessene Ressource: Jeder Zustandsübergang verwendet optimistische Nebenläufigkeit in Aurora (WHERE status=expected_status AND version=expected_version).
• Redis SETNX bietet eine schnelle erste Ablehnungslinie bei 8k RPS, ohne die DB zu belasten; das Aurora-Zeilenupdate ist die zweite Linie und die rechtsverbindliche Wahrheit.
• Alle Schreibvorgänge auf der Zahlungsseite sind idempotent durch die Eindeutigkeit von provider_ref + DynamoDB-Deduplizierungstabelle.
• Das Outbox-Muster stellt sicher, dass Domain-Events relativ zu DB-Commits exakt einmal an Kafka veröffentlicht werden.
• Starke Konsistenz innerhalb einer einzelnen Sitzzeile; Eventual Consistency ist nur für aggregierte Verfügbarkeitszählungen akzeptabel, die in Browse-Ansichten angezeigt werden.

8. Skalierungsstrategie für Spitzen

• Virtueller Warteraum: Wenn concurrent_users > threshold, erhalten neue Nutzer ein Queue-Token; nur N Tokens/Sek. werden zu den Reservierungs-Endpunkten zugelassen. Hält das System bei bekannter Kapazität (z. B. 10k/Sek. zulassen, um 8k Reservierungsversuche/Sek. abzufangen).
• Horizontales Autoscaling (HPA auf EKS) auf CPU- und benutzerdefinierten RPS-Metriken; Pods 15 Minuten vor angekündigten Verkäufen vorwärmen.
• Sharding heißer Events: Redis-Schlüssel nach event_id partitionieren, sodass ein einzelnes Mega-Event auf einem dedizierten Shard landet; Shards für bekannte Verkäufe können vorab bereitgestellt werden.
• Leseskalierung: Aurora-Read-Replicas + Redis für Verfügbarkeit + CDN für statische Sitzplandaten.
• Backpressure: API-Gateway-Request-Quoten pro Nutzer; 429 mit Retry-After.
• Asynchrones Fan-out: Kafka entkoppelt Ticketgenerierung, E-Mail und Analytik vom Hot Path.
• Connection Pooling: RDS Proxy / PgBouncer, um Aurora-Verbindungsstürme zu vermeiden.
• Bot-Abwehr: WAF, CAPTCHA auf POST /reservations während Verkäufen, Device-Fingerprinting.

9. Zuverlässigkeit & Disaster Recovery

• Multi-AZ für jede zustandsbehaftete Komponente (Aurora, Redis mit Replicas + automatischem Failover, MSK RF=3, DynamoDB).
• Aurora: kontinuierliches Backup nach S3, PITR auf jede Sekunde innerhalb der Aufbewahrung → RPO ≤ 1 min erfüllt; Failover ~30–60s → RTO ≤ 15 min erfüllt.
• Redis: Multi-AZ mit automatischem Failover; Daten sind aus Aurora rekonstruierbar (Holds können bei einem Kaltstart aus reservations WHERE state='pending_payment' neu aufgebaut werden).
• Kafka: Tiered Storage, RF=3, min ISR=2.
• DR-Runbook: Cross-Region-Aurora-Global-Database-Replica (RPO ~ Sekunden) für die Wiederherstellung nach regionsweiten Ausfällen; dokumentiertes Promotion-Verfahren.
• Chaos-Übungen: AZ-Blackout, Redis-Primary-Kill, Simulation eines Zahlungsanbieter-Ausfalls, vierteljährlich.
• Health Checks auf ALB-Ebene; Circuit Breaker (Resilience4j-artig) zwischen Diensten und in Richtung Zahlungsanbieter.
• Graceful Degradation: Ist Redis nicht verfügbar, Rückfall auf den reinen DB-Pfad mit strengerem Rate Limit; ist der Zahlungsanbieter ausgefallen, Checkouts in eine Queue stellen und den Nutzer benachrichtigen.

10. Monitoring & Alerting

• Metriken (Prometheus + CloudWatch): RPS, p50/p95/p99-Latenz pro Endpunkt, Reservierungserfolgsrate, Hold-Acquire-Konfliktrate, Payment-Webhook-Verzögerung, Expiration-Worker-Verzögerung, Aurora-Replica-Lag, Redis-CPU/-Speicher/-Evictions, Kafka-Consumer-Lag.
• SLOs: 99,95% Verfügbarkeit im Verkaufsfenster; p95 Browse < 300 ms; p95 Reservierung < 800 ms; Alerts bei Verbrauch des Error Budgets.
• Tracing: OpenTelemetry Ende-zu-Ende (Client → API → Service → DB).
• Logging: strukturiertes JSON nach CloudWatch/Elastic; Correlation IDs.
• Business-Dashboards: Holds/Sek., Conversion (Hold→bezahlt), Überverkaufs-Zähler (muss 0 sein — Alarmierung bei jedem Wert ungleich null).
• Alerts: Verletzung von oversell=0 (P0), Webhook-Rückstau > 1 min, Reservierung p95 > 800 ms über 5 min, Aurora-Failover, Redis-Failover, Rückgang der Zahlungserfolgsrate > 2σ.

11. Wesentliche Kompromisse und Alternativen

• Redis als Hold-Autorität vs. reine DB: Der reine DB-Ansatz ist einfacher und stärker, könnte aber 8k RPS auf Single-Row-Hotspots nicht durchhalten; Redis-first fängt die Spitze ab, das DB-Zeilenupdate garantiert die Korrektheit.
• Pessimistische Sperren (SELECT FOR UPDATE): erwogen; verworfen, weil Sperrkonkurrenz auf beliebten Sektionen den Durchsatz einbrechen ließe. Optimistisches Sperren mit Retries skaliert besser.
• Reservierte Bestuhlung vs. General-Admission-Zähler: Der obige Entwurf ist sitzbasiert. Für GA wird stattdessen ein einzelner dekrementierender Zähler (DECR in Redis mit Untergrenze 0, gespiegelt zur DB) verwendet.
• Single-Region vs. Multi-Region Active-Active: Die Vorgabe nennt eine Region. Active-Active würde „niemals überverkaufen" verkomplizieren (regionsübergreifender Konsens erforderlich). Wir nutzen ein Cross-Region-Read-Replica nur für DR.
• Kafka vs. SQS: Kafka gewählt für ein geordnetes, wiederholbares Event-Log (hilft bei der Zahlungsverarbeitung in falscher Reihenfolge und beim Wiederaufbau des Zustands).
• Synchrone Zahlung vs. reines Webhook: reines Webhook gewählt, um PCI-leicht zu bleiben und Anbieterlatenz zu tolerieren; Webhook-Verzögerungen von bis zu 5 min passen weiterhin in das 10-minütige Hold-Fenster.
• Warteraum vs. reines Autoscaling: Autoscaling allein kann nachgelagerte zustandsbehaftete Stores nicht schützen; die Queue liefert eine deterministische Lastform und eine bessere UX als massenhafte 503er.
• Tickets synchron vs. asynchron ausgeben: asynchron über Kafka hält den Payment-Callback-Handler schnell und robust; der Nutzer sieht das Ticket innerhalb von Sekunden per Push/Refresh.

Dieser Entwurf erfüllt die genannten SLOs, verhindert Überverkäufe durch mehrschichtige optimistische Nebenläufigkeit, fängt Verkaufsspitzen über die virtuelle Queue + Redis-vorgelagerte Holds ab und erfüllt die RPO/RTO-Ziele durch Multi-AZ-verwaltete Stores mit PITR und eingeübtem Failover.

Systemdesign: Skalierbares Konzertticket-Reservierungssystem

1. Hauptservices und Datenspeicher

Services:

• API Gateway: Einstiegspunkt für alle Client-Anfragen; übernimmt Authentifizierung, Rate Limiting und Request-Routing.
• User Service: Verwaltet Benutzerregistrierung, Profile und Authentifizierung.
• Event Service: Verwaltet Veranstaltungsdetails, Zeitpläne und statische Inhalte.
• Seat Service: Verwaltet Sitzplatzinventar, Verfügbarkeit und Sitzplan-Daten für Veranstaltungen.
• Reservation Service: Behandelt die Sitzplatz-Reservierungslogik und verwaltet Reservierungs-Lebenszyklen (ausstehend, bestätigt, abgelaufen).
• Payment Service (intern): Orchestriert Interaktionen mit externen Zahlungsanbietern, verarbeitet Callbacks und verwaltet interne Zahlungsdatensätze.
• Notification Service: Versendet digitale Tickets, Bestätigungs-E-Mails und andere Benutzerbenachrichtigungen.
• Queueing Service (Kafka): Asynchrone Kommunikation zwischen Services; verarbeitet Ereignisse mit hohem Durchsatz (z. B. Zahlungs-Callbacks, Reservierungsablauf).
• Cache Service (Redis): Hochgeschwindigkeits-Datenzugriff für Sitzplatzverfügbarkeit, Veranstaltungsdetails und verteilte Sperren.
• Background Worker Service: Verarbeitet asynchrone Aufgaben wie Reservierungsablauf, Wiederholungen von Zahlungs-Callbacks und Datenbereinigung.

Datenspeicher:

• PostgreSQL (relationale Datenbank): Primärer Datenspeicher für Benutzer, Veranstaltungen, Sitzplätze, Reservierungen und Zahlungen. Gewählt aufgrund starker ACID-Eigenschaften, die entscheidend sind, um Überverkäufe zu verhindern.
  • Bereitstellung: Multi-AZ, Primär-Replikat-Setup mit synchroner Replikation für kritische Tabellen (seats, reservations) und asynchroner Replikation für andere.
• Redis (In-Memory-Datenspeicher): Verwendet für:
  • Caching der Sitzplatzverfügbarkeit und Veranstaltungsdetails.
  • Verteilte Sperren für Sitzplatzreservierung und -bestätigung.
  • Temporäre Timer für den Reservierungsablauf (TTL-Schlüssel).
• Kafka (verteilte Streaming-Plattform): Für zuverlässige, asynchrone Nachrichtenübermittlung und Event Sourcing.
• Objektspeicher (z. B. S3): Speichert statische Assets wie Veranstaltungsbilder, Künstlerfotos und potenziell digitale Ticket-PDFs.

2. Kern-APIs

User Service:

• POST /users/register: Registriert einen neuen Benutzer.
• POST /users/login: Authentifiziert einen Benutzer.
• GET /users/{id}: Ruft das Benutzerprofil ab.

Event Service:

• GET /events: Alle Veranstaltungen durchsuchen (paginert).
• GET /events/{id}: Ruft Details zu einer bestimmten Veranstaltung ab.
• GET /events/{id}/seatmap: Ruft den Sitzplan und die aktuelle Verfügbarkeit für eine Veranstaltung ab.

Reservation Service:

• POST /events/{id}/reserve: Reserviert bestimmte Sitzplätze für eine Veranstaltung. Eingabe: event_id, seat_ids, user_id. Ausgabe: reservation_id, expires_at.
• GET /reservations/{id}: Ruft Reservierungsdetails ab.
• DELETE /reservations/{id}: Storniert eine ausstehende Reservierung.
• POST /reservations/{id}/confirm: Bestätigt eine Reservierung nach erfolgreicher Zahlung (interne API, ausgelöst durch den Payment Service).

Payment Service:

• POST /payments/initiate: Startet die Zahlung für eine Reservierung. Eingabe: reservation_id, amount, user_id. Ausgabe: Weiterleitungs-URL des Zahlungsanbieters.
• POST /payments/callback: Webhook-Endpunkt für Callbacks externer Zahlungsanbieter (intern).

Ticket Service (Teil des Notification/Reservation Service):

• GET /tickets/{id}: Ruft ein digitales Ticket ab.

3. Datenmodell für Sitzplätze und Reservierungen

Tabelle: users

• user_id (PK, UUID)
• username (VARCHAR, UNIQUE)
• email (VARCHAR, UNIQUE)
• password_hash (VARCHAR)
• created_at (TIMESTAMP)

Tabelle: events

• event_id (PK, UUID)
• name (VARCHAR)
• venue (VARCHAR)
• date_time (TIMESTAMP)
• total_seats (INT)
• image_url (VARCHAR)

Tabelle: seats

• seat_id (PK, UUID)
• event_id (FK auf events.event_id)
• section (VARCHAR)
• row_number (VARCHAR)
• seat_number (VARCHAR)
• price (DECIMAL)
• status (ENUM: 'available', 'reserved', 'sold')
• version (INT, für optimistisches Locking)

Tabelle: reservations

• reservation_id (PK, UUID)
• user_id (FK auf users.user_id)
• event_id (FK auf events.event_id)
• status (ENUM: 'pending', 'confirmed', 'expired', 'cancelled')
• reserved_at (TIMESTAMP)
• expires_at (TIMESTAMP)
• payment_id (FK auf payments.payment_id, nullable)
• total_amount (DECIMAL)
• created_at (TIMESTAMP)
• updated_at (TIMESTAMP)

Tabelle: reservation_seats (Junction Table)

• reservation_id (FK auf reservations.reservation_id)
• seat_id (FK auf seats.seat_id)
• (Zusammengesetzter PK: reservation_id, seat_id)

Tabelle: payments

• payment_id (PK, UUID)
• reservation_id (FK auf reservations.reservation_id)
• user_id (FK auf users.user_id)
• amount (DECIMAL)
• currency (VARCHAR)
• provider_transaction_id (VARCHAR, UNIQUE)
• status (ENUM: 'initiated', 'pending', 'succeeded', 'failed', 'refunded')
• created_at (TIMESTAMP)
• updated_at (TIMESTAMP)

4. Anfragefluss

A. Veranstaltungen durchsuchen & Sitzplatzverfügbarkeit anzeigen:

1. Benutzeranfrage: Der Browser/die App des Benutzers fordert /events oder /events/{id}/seatmap an.
2. CDN: Liefert statische Assets (Veranstaltungsbilder, JS/CSS), falls gecacht.
3. API Gateway: Authentifiziert den Benutzer und leitet die Anfrage an den Event Service oder Seat Service weiter.
4. Event Service: Ruft Veranstaltungsdetails aus PostgreSQL (oder dem Redis-Cache) ab.
5. Seat Service: Ruft Sitzplan und Verfügbarkeit aus dem Redis-Cache ab. Falls nicht im Cache vorhanden, wird die PostgreSQL-Tabelle seats abgefragt, der Cache aktualisiert und die Daten zurückgegeben.
6. Antwort: Daten werden an den Benutzer zurückgegeben. (P95-Latenz < 300 ms).

B. Sitzplätze reservieren:

1. Benutzeranfrage: Der Benutzer wählt Sitzplätze aus und klickt auf „Reserve“, wodurch POST /events/{id}/reserve mit event_id, seat_ids, user_id gesendet wird.
2. API Gateway: Leitet an den Reservation Service weiter.
3. Reservation Service:
   • Verteilte Sperre: Erwirbt für jede seat_id eine verteilte Sperre in Redis, um gleichzeitige Änderungen zu verhindern. (z. B. LOCK:seat:{seat_id}).
   • Prüfung des Sitzplatzstatus: Fragt die Tabelle seats (oder den Redis-Cache) ab, um zu verifizieren, dass die ausgewählten Sitzplätze „available“ sind.
   • Transaktion: Startet eine Datenbanktransaktion.
   • Sitzplätze aktualisieren: Aktualisiert den status der ausgewählten Sitzplätze in der Tabelle seats auf „reserved“.
   • Reservierung erstellen: Fügt einen neuen Datensatz in die Tabelle reservations mit status='pending', reserved_at und expires_at (aktuelle Zeit + 10 Minuten) ein.
   • Sitzplätze verknüpfen: Fügt für jeden reservierten Sitzplatz Datensätze in reservation_seats ein.
   • Transaktion committen.
   • Redis-TTL setzen: Setzt einen Redis-Schlüssel (z. B. RESERVATION_EXPIRY:{reservation_id}) mit einer TTL von 10 Minuten. Dies fungiert als schneller Ablauf-Trigger.
   • Sperren freigeben: Gibt die verteilten Sperren für die Sitzplätze frei.
4. Antwort: Gibt reservation_id und expires_at an den Benutzer zurück. (P95-Latenz < 800 ms ohne Zahlung).

C. Für eine Reservierung bezahlen:

1. Benutzeraktion: Der Benutzer initiiert die Zahlung für eine pending-Reservierung.
2. Benutzeranfrage: Browser/App sendet POST /payments/initiate mit reservation_id an den Payment Service.
3. Payment Service (intern):
   • Erstellt einen payment-Datensatz mit status='initiated'.
   • Ruft die API des externen Zahlungsanbieters (z. B. Stripe, PayPal) mit Reservierungsdetails und Betrag auf.
   • Leitet den Benutzer auf die Seite des Zahlungsanbieters weiter.
4. Externer Zahlungsanbieter: Verarbeitet die Zahlung.
5. Callback des Zahlungsanbieters: Bei erfolgreicher/fehlgeschlagener Zahlung sendet der externe Anbieter asynchron einen Webhook POST /payments/callback an den Payment Service.
6. Payment Service (intern) - Callback-Handler:
   • Idempotenzprüfung: Verwendet provider_transaction_id, um sicherzustellen, dass der Callback nur einmal verarbeitet wird.
   • Aktualisiert den Status des payment-Datensatzes (succeeded oder failed).
   • Veröffentlicht ein PaymentConfirmed- oder PaymentFailed-Ereignis in Kafka, einschließlich reservation_id und payment_id.
7. Reservation Service - Kafka Consumer:
   • Konsumiert das PaymentConfirmed-Ereignis.
   • Verteilte Sperre: Erwirbt eine Sperre für die reservation_id.
   • Transaktion: Startet eine Datenbanktransaktion.
   • Reservierung aktualisieren: Aktualisiert die Tabelle reservations: status='confirmed', verknüpft payment_id.
   • Sitzplätze aktualisieren: Aktualisiert den status der zugehörigen Sitzplätze in der Tabelle seats auf „sold“.
   • Transaktion committen.
   • Redis-TTL entfernen: Löscht den Schlüssel RESERVATION_EXPIRY:{reservation_id} aus Redis.
   • Sperre freigeben.
   • Veröffentlicht ein TicketIssued-Ereignis in Kafka.
8. Notification Service - Kafka Consumer: Konsumiert das TicketIssued-Ereignis, erzeugt ein digitales Ticket und sendet dem Benutzer eine E-Mail-/Push-Benachrichtigung.

D. Reservierungen ablaufen lassen:

1. Redis-Keyspace-Events / Background Worker:
   • Schneller Pfad (Redis TTL): Wenn ein RESERVATION_EXPIRY:{reservation_id}-Schlüssel in Redis abläuft, wird ein Keyspace-Event ausgelöst. Ein dedizierter Microservice oder Background Worker konsumiert dieses Ereignis.
   • Robuster Pfad (DB-Scan): Ein Background Worker Service scannt periodisch (z. B. alle 30 Sekunden) die Tabelle reservations nach Datensätzen, bei denen status='pending' und expires_at < current_time gilt.
2. Background-Worker-Logik:
   • Für jede abgelaufene pending-Reservierung:
     • Verteilte Sperre: Erwirbt eine Sperre für die reservation_id.
     • Status prüfen: Verifiziert, dass die Reservierung noch pending ist (um zu vermeiden, dass bereits bezahlte Reservierungen aufgrund von Race Conditions oder verzögerten Ereignissen ablaufen).
     • Transaktion: Startet eine Datenbanktransaktion.
     • Reservierung aktualisieren: Aktualisiert die Tabelle reservations: status='expired'.
     • Sitzplätze aktualisieren: Aktualisiert den status der zugehörigen Sitzplätze in der Tabelle seats zurück auf „available“.
     • Transaktion committen.
     • Sperre freigeben.

5. Skalierungsstrategie für Verkehrsspitzen

• Zustandslose Services: Alle Anwendungsservices (User, Event, Seat, Reservation, Payment, Notification) sind so konzipiert, dass sie zustandslos sind, was horizontale Skalierung ermöglicht.
• Auto-Scaling Groups (ASG): Services werden in ASGs bereitgestellt, die Instanzen auf Basis von Metriken wie CPU-Auslastung, Tiefe der Anfragewarteschlange oder benutzerdefinierten Metriken (z. B. aktive Reservierungen) automatisch hinzufügen/entfernen.
• Load Balancers: Application Load Balancers (ALBs) verteilen eingehenden Datenverkehr über mehrere Availability Zones hinweg auf gesunde Instanzen jedes Services.
• CDN: Ein Content Delivery Network cached statische Assets (Veranstaltungsbilder, JS, CSS), um Datenverkehr von Backend-Services fernzuhalten und die Latenz für Benutzer zu reduzieren.
• Caching (Redis): Der umfangreiche Einsatz von Redis zum Caching häufig abgefragter Daten (Sitzplatzverfügbarkeit, Veranstaltungsdetails) reduziert die Datenbanklast erheblich, insbesondere beim leseintensiven Durchsuchen und bei Sitzplanansichten.
• Queues (Kafka): Kafka fungiert als Puffer, entkoppelt Services und fängt Verkehrsspitzen ab. Asynchrone Operationen (Zahlungs-Callbacks, Benachrichtigungen, Verarbeitung ablaufender Reservierungen) werden an Kafka übergeben, sodass Services sie in ihrem eigenen Tempo verarbeiten können, ohne Benutzeranfragen zu blockieren.
• Datenbank-Lesereplikate: PostgreSQL-Instanzen sind mit mehreren Lesereplikaten konfiguriert. Leseintensive Services (Event Service, Seat Service für Sitzpläne) können ihre Abfragen an diese Replikate richten und so die Primärdatenbank entlasten.
• Datenbank-Sharding (potenzielle Zukunft): Falls eine einzelne PostgreSQL-Instanz zum Schreib-Bottleneck wird, könnte Sharding nach event_id oder user_id in Betracht gezogen werden. Dies würde die Verteilung der Daten über mehrere Datenbankinstanzen hinweg bedeuten.
• Connection Pooling: Effiziente Verwaltung von Datenbankverbindungen zur Minimierung von Overhead und Maximierung des Durchsatzes.
• Rate Limiting: Wird im API Gateway implementiert, um Backend-Services vor missbräuchlichem Datenverkehr oder plötzlichen, überwältigenden Spitzen zu schützen.

6. Ansatz für Zuverlässigkeit und Disaster Recovery

• Multi-Availability-Zone-(Multi-AZ)-Bereitstellung: Alle Services und Datenspeicher werden über mindestens drei Availability Zones innerhalb der Cloud-Region hinweg bereitgestellt. Dies bietet Resilienz gegen Ausfälle auf AZ-Ebene.
• Datenbankreplikation & Failover:
  • PostgreSQL: Primär-Replikat-Setup. Kritische Daten (seats, reservations) verwenden synchrone Replikation, um RPO < 1 Minute sicherzustellen. Automatisierte Failover-Mechanismen (z. B. Patroni, cloudverwaltetes RDS-Failover) befördern bei Ausfall der Primärinstanz ein Replikat zur Primärinstanz und erreichen so RTO < 15 Minuten.
  • Redis: Sentinel- oder Cluster-Modus für hohe Verfügbarkeit, mit über Knoten in verschiedenen AZs replizierten Daten.
• Kafka-Dauerhaftigkeit: Kafka-Broker werden über mehrere AZs hinweg mit Replikationsfaktor > 1 (z. B. 3) bereitgestellt, um Nachrichtenhaltbarkeit und Verfügbarkeit sicherzustellen, selbst wenn eine AZ oder ein Broker ausfällt.
• Automatisierte Backups: Regelmäßige, automatisierte Backups von PostgreSQL in Objektspeicher mit Point-in-Time-Recovery-Fähigkeiten. Snapshots für Redis.
• Zustandslose Services: Services sind zustandslos konzipiert, was bedeutet, dass jede Instanz ohne Datenverlust ersetzt oder neu gestartet werden kann und so zu hoher Verfügbarkeit beiträgt.
• Circuit Breakers & Retries: Werden in der Service-zu-Service-Kommunikation implementiert, um kaskadierende Ausfälle zu verhindern. Services degradieren kontrolliert oder wiederholen fehlgeschlagene Anfragen.
• Graceful Degradation: Bei extremer Last könnten nicht kritische Funktionen (z. B. personalisierte Empfehlungen) vorübergehend deaktiviert werden, um Kernfunktionalitäten (Reservierung, Zahlung) zu priorisieren.
• Recovery Point Objective (RPO) < 1 Minute: Erreicht durch synchrone Datenbankreplikation für kritische Daten und Kafkas dauerhaftes Nachrichten-Logging mit geeigneten Replikationseinstellungen.
• Recovery Time Objective (RTO) < 15 Minuten: Erreicht durch automatisiertes Datenbank-Failover, Auto-Scaling der Anwendungsservices und vorgewärmte Instanzen oder schnelle Bereitstellungsfähigkeiten.

7. Konsistenzentscheidungen zur Verhinderung von Überverkäufen

Die Verhinderung von Überverkäufen ist von höchster Bedeutung und erfordert starke Konsistenz bei Aktualisierungen des Sitzplatzstatus.

• Verteilte Sperren (Redis): Wenn ein Benutzer versucht, Sitzplätze zu reservieren, erwirbt der Reservation Service in Redis für jede spezifische seat_id eine verteilte Sperre. Dies stellt sicher, dass zu jedem Zeitpunkt nur ein Reservierungsversuch den Status eines bestimmten Sitzplatzes ändern kann. Die Sperre wird für die Dauer der Datenbanktransaktion gehalten, die den Sitzplatzstatus aktualisiert und die Reservierung erstellt.
• ACID-Transaktionen (PostgreSQL): Alle Aktualisierungen des seats-Status sowie das Erstellen/Aktualisieren von reservations-Datensätzen erfolgen innerhalb einer einzigen ACID-Transaktion in PostgreSQL. Dies garantiert Atomarität, Konsistenz, Isolation und Dauerhaftigkeit. Wenn irgendein Teil der Transaktion fehlschlägt (z. B. weil ein anderer Benutzer bereits einen Sitzplatz reserviert hat), wird die gesamte Transaktion zurückgerollt, sodass keine Teilaktualisierungen entstehen und Überverkäufe verhindert werden.
• Optimistische Nebenläufigkeitskontrolle (Versionsnummern): Für die Tabelle seats kann eine version-Spalte hinzugefügt werden. Beim Aktualisieren des Sitzplatzstatus enthält die UPDATE-Abfrage ein WHERE version = <old_version>. Wenn die Version nicht übereinstimmt, bedeutet dies, dass eine andere Transaktion den Sitzplatz geändert hat, und die aktuelle Transaktion kann wiederholt oder abgelehnt werden. Dies bietet eine zusätzliche Schutzschicht gegen Race Conditions, insbesondere wenn verteilte Sperren versagen oder nicht perfekt implementiert sind.
• Idempotente Zahlungsverarbeitung: Callbacks von Zahlungsanbietern sind at-least-once und können in falscher Reihenfolge eintreffen. Der Payment Service verarbeitet diese Callbacks idempotent und verwendet provider_transaction_id, um sicherzustellen, dass eine erfolgreiche Zahlung nur einmal auf eine Reservierung angewendet wird; dadurch werden doppelte Bestätigungen oder inkorrekte Statusaktualisierungen verhindert.
• Reservierungsablauf-Logik: Der Ablaufprozess prüft explizit, ob eine Reservierung noch pending ist, bevor sie als expired markiert und die Sitzplätze freigegeben werden. Dies verhindert eine Race Condition, bei der eine Zahlung genau dann eingehen könnte, wenn der Ablaufprozess kurz vor der Ausführung steht.

8. Monitoring und Alarmierung

• Metrikerfassung: Verwenden Sie Prometheus/Grafana oder cloudnative Überwachung (z. B. CloudWatch, Stackdriver), um Metriken aus allen Services, Datenbanken, Caches und Queues zu erfassen. Zu den zentralen Metriken gehören:
  • Systemmetriken: CPU-Auslastung, Speichernutzung, Festplatten-I/O, Netzwerk-I/O.
  • Anwendungsmetriken: Anfrageraten, Fehlerraten (5xx), Latenz (p95, p99) für alle API-Endpunkte, Queue-Tiefen, aktive Verbindungen, Garbage Collection.
  • Datenbankmetriken: Abfragelatenz, Nutzung des Connection Pools, Transaktionsraten, Replikationsverzug, Deadlocks.
  • Cache-Metriken: Cache-Treffer-/Fehlerrate, Speichernutzung.
  • Kafka-Metriken: Producer-/Consumer-Lag, Nachrichtenraten, Broker-Gesundheit.
• Zentralisiertes Logging: Aggregieren Sie Logs aus allen Services in ein zentrales Logging-System (z. B. ELK-Stack, Splunk, Datadog). Verwenden Sie strukturiertes Logging für einfacheres Parsen und Analysieren.
• Verteiltes Tracing: Implementieren Sie verteiltes Tracing (z. B. OpenTelemetry, Jaeger), um Anfrageflüsse über mehrere Services hinweg zu visualisieren, Bottlenecks zu identifizieren und komplexe Interaktionen zu debuggen.
• Alarmierung: Konfigurieren Sie Alarme für kritische Schwellenwerte:
  • Hohe Fehlerraten (z. B. 5 % 5xx-Fehler über 5 Minuten).
  • Hohe Latenz (z. B. p95-API-Latenz > 800 ms).
  • Service-Ausfallzeiten oder ungesunde Instanzen.
  • Datenbank-Replikationsverzug, der Schwellenwerte überschreitet.
  • Queue-Rückstände.
  • Fehlgeschlagene Zahlungs-Callbacks oder Fehler beim Reservierungsablauf.
  • Erschöpfung von Ressourcen (CPU, Speicher, Festplatte).
• Dashboards: Erstellen Sie Echtzeit-Dashboards für operative Transparenz, die zentrale Metriken und die Gesundheit der Services anzeigen.

9. Zentrale Trade-offs oder Alternativen

• Datenbankwahl:
  • Alternative: NoSQL-Datenbank (z. B. Cassandra, DynamoDB) für extreme Schreibskalierbarkeit. Trade-off: Obwohl NoSQL enorme Skalierung bewältigen kann, ist das Erreichen starker Konsistenz für komplexe transaktionale Operationen wie Sitzplatzreservierungen (die mehrere Aktualisierungen und Prüfungen umfassen) deutlich schwieriger und erfordert oft komplexe Logik auf Anwendungsebene. Die ACID-Eigenschaften von PostgreSQL vereinfachen die Verhinderung von Überverkäufen, und seine Skalierbarkeit kann durch Lesereplikate und Sharding verwaltet werden.
• Sperrmechanismus:
  • Alternative: Row Locks auf Datenbankebene. Trade-off: Kann in Szenarien mit hoher Nebenläufigkeit zu stärkerer Kontention und potenziellen Deadlocks führen und damit die Performance beeinträchtigen. Verteilte Redis-Sperren sind im Allgemeinen schneller und entlasten die Datenbank vom Sperrmechanismus, erfordern jedoch eine sorgfältige Implementierung (z. B. Behandlung des Sperrablaufs, Sicherstellung der Atomarität von Sperrerwerb/-freigabe).
• Reservierungsablauf:
  • Alternative: Ausschließliches Verlassen auf Redis-TTL-Keyspace-Events. Trade-off: Obwohl schnell, ist bei Redis-Keyspace-Events keine garantierte Zustellung gegeben (z. B. wenn Redis neu startet oder Ereignisse verpasst werden). Der gewählte Ansatz kombiniert Redis-TTL für einen schnellen Pfad mit einem robusten Background Worker, der die Datenbank für eventual consistency scannt und sicherstellt, dass keine Reservierung dauerhaft in pending hängen bleibt.
• Behandlung von Zahlungs-Callbacks:
  • Alternative: Synchroner Callback vom Zahlungsanbieter. Trade-off: Dies wird von externen Anbietern nur selten angeboten und würde verlangen, dass die Plattform gegenüber dem Zahlungsanbieter hochverfügbar und reaktionsschnell ist, was eine enge Kopplung einführt. Der asynchrone at-least-once-Ansatz über Kafka ist Standard und widerstandsfähiger, erfordert jedoch idempotente Verarbeitung und den Umgang mit Nachrichten außerhalb der Reihenfolge.
• Microservices vs. Monolith:
  • Alternative: Monolithische Architektur. Trade-off: Anfangs einfacher zu entwickeln, aber schwieriger, einzelne Komponenten zu skalieren, unabhängig bereitzustellen und für große Teams zu verwalten. Microservices bieten bessere Skalierbarkeit, Fehlerisolation und technologische Vielfalt, führen jedoch zu betrieblicher Komplexität (verteilte Transaktionen, Monitoring, Deployment).

10. Annahmen

• Benutzerauthentifizierung: Benutzer sind authentifiziert, bevor sie Aktionen ausführen, die eine Identität erfordern (z. B. Sitzplätze reservieren, Tickets ansehen).
• PCI-Compliance: Der externe Zahlungsanbieter erfüllt alle PCI-DSS-Compliance-Anforderungen; der interne Payment Service orchestriert lediglich und speichert minimale, nicht sensible Zahlungsdaten.
• Kapazität der Cloud-Region: Die gewählte Cloud-Region verfügt über ausreichende Rechen-, Netzwerk- und Speicherkapazität, um die angegebenen Spitzenlasten zu bewältigen.
• Netzwerklatenz: Die interne Netzwerklatenz innerhalb der Cloud-Region und zwischen Availability Zones ist niedrig genug, um die Latenzziele einzuhalten.
• Sicherheit: Standard-Sicherheitspraktiken (z. B. Verschlüsselung während der Übertragung und im Ruhezustand, Eingabevalidierung, Zugriffskontrolle, Schwachstellenscans) sind im gesamten System implementiert, werden in diesem Design jedoch nicht im Detail beschrieben.
• Zuverlässigkeit des externen Zahlungsanbieters: Es wird angenommen, dass der externe Zahlungsanbieter hochverfügbar und zuverlässig bei der Zahlungsabwicklung und dem Senden von Callbacks ist.