Entwurf eines skalierbaren Ticketreservierungssystems für Konzerte

# Scalable Concert Ticket Reservation System — Design Plan ## 1. Assumptions - Single cloud region (e.g., AWS us-east-1) with 3 AZs; managed services preferred. - Catalog (events, venues, seat maps) is read-heavy and changes infrequently. - Reservations are the hot path; payments are off-hot-path via async callbacks. - "Never oversell" is a hard invariant; brief unavailability is preferred over double-selling. - An external payment provider (e.g., Stripe/Adyen) handles PCI scope; we store only tokens. - Average event size 30k seats; peak burst lasts minutes to ~1 hour. ## 2. High-Level Architecture Clients (web/mobile) → CDN (CloudFront) → API Gateway / L7 Load Balancer → Edge auth (JWT) → Stateless microservices on Kubernetes (EKS) across 3 AZs. Core services: - **Identity Service**: signup, login, JWT issuance, MFA. - **Catalog Service**: events, venues, seat-map metadata; read-optimized. - **Inventory/Seat Service**: authoritative seat state, holds, reservations; the consistency anchor. - **Reservation Service**: orchestrates hold → checkout → payment intent. - **Payment Service**: integrates with provider, processes webhook callbacks idempotently. - **Ticket Service**: issues signed digital tickets (JWT/QR) after payment success. - **Notification Service**: email/push (SES/SNS). - **Waiting Room / Virtual Queue Service**: throttles entry during on-sale spikes. - **Expiration Worker**: releases unpaid holds after 10 minutes. - **Admin/Onsale Service**: event configuration, seat-map upload, on-sale scheduling. Cross-cutting: Kafka (MSK) for events, Redis (ElastiCache, cluster mode) for hot state and locks, PostgreSQL (Aurora Multi-AZ) for transactional data, DynamoDB for idempotency keys and ticket store, S3 for seat-map JSON/images, OpenSearch for event search. ## 3. Data Stores - **Aurora PostgreSQL (Multi-AZ, 1 writer + 2 readers)**: events, users, reservations, payments, tickets (system of record). Continuous backup; PITR. - **Redis Cluster (Multi-AZ, with replicas)**: per-seat hold state, per-event seat bitmap cache, rate limits, waiting room tokens. Used for fast CAS on holds. - **DynamoDB**: payment idempotency keys, webhook dedupe, issued-ticket lookup (low-latency, multi-AZ by default). - **Kafka (MSK)**: domain events (`SeatHeld`, `ReservationCreated`, `PaymentSucceeded`, `PaymentFailed`, `ReservationExpired`, `TicketIssued`). Replication factor 3 across AZs. - **S3**: static seat-map artifacts, ticket PDFs. - **CDN**: caches event listings, seat-map skeleton (not live availability). - **OpenSearch**: event search/filtering. ## 4. Core Data Model **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). Composite index (event_id, status). Row-level versioning for optimistic locking. **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 on provider_ref for at-least-once dedupe. **tickets**(ticket_id PK, reservation_id, seat_id, qr_payload, issued_at, signature). **outbox**(id, aggregate, payload, published_at) for transactional outbox pattern → Kafka. Redis keys: - `event:{id}:seat:{seat_id}` → status + hold owner + TTL 600s. - `event:{id}:availability` → bitmap/HLL for fast counts. - `hold:{reservation_id}` → seat list, TTL 600s. ## 5. Core APIs (REST + idempotency headers) - `GET /events?filters` → paginated list (CDN-cacheable, 30s TTL). - `GET /events/{id}` → event details. - `GET /events/{id}/seatmap` → static layout (long cache). - `GET /events/{id}/availability` → coarse availability (sections); 1–5s cache. - `GET /events/{id}/seats?section=A` → fine-grained seat status (short cache or live). - `POST /reservations` (Idempotency-Key) → `{event_id, seat_ids[]}` → creates 10-min hold. - `GET /reservations/{id}` → state, expires_at. - `DELETE /reservations/{id}` → user cancels, releases seats. - `POST /reservations/{id}/checkout` → creates payment intent at provider, returns client secret. - `POST /webhooks/payments` → provider callback (signed, idempotent). - `GET /tickets/{id}` → signed digital ticket. - Admin: `POST /events`, `POST /events/{id}/seats:bulk`, `POST /events/{id}/onsale`. ## 6. Request Flows ### Browsing Client → CDN (hit for catalog/seatmap) → on miss, API → Catalog Service → Aurora reader / OpenSearch. Availability counts served from Redis with 1–5s staleness; individual seat states pulled live for the section the user is viewing. ### Reservation (hold) 1. Client sends `POST /reservations` with Idempotency-Key and target seats. 2. API Gateway checks waiting-room token; rate-limits per user/IP. 3. Reservation Service validates event status and seat IDs. 4. **Acquire holds atomically** via Redis Lua script: for each seat key, `SETNX` with hold_id and TTL 600s; if any seat fails, roll back the successful ones and return 409 with conflicting seats. 5. Persist reservation row in Aurora in `pending_payment` state (single transaction with outbox event). Use optimistic locking on seats: `UPDATE seats SET status='held', hold_id=?, version=version+1 WHERE seat_id=? AND status='available'`. Aurora is the durable truth; Redis is the fast guard. Both must agree. 6. Return reservation with `expires_at`. p95 < 800 ms. ### Payment 1. Client calls `POST /reservations/{id}/checkout`; Payment Service creates a PaymentIntent at provider, stores `provider_ref` keyed by reservation_id (idempotent). 2. Client completes payment via provider SDK directly (we stay out of PCI scope). 3. Provider sends webhook → `POST /webhooks/payments`. 4. Webhook handler: verify signature → upsert into `payments` using `provider_ref` UNIQUE (dedupe). Use DynamoDB conditional put on event_id for extra idempotency. 5. On `succeeded`: transactional update — reservation→`confirmed`, seats→`sold`, write `tickets`, append outbox event `TicketIssued`. Out-of-order safety: handler compares event timestamps and ignores stale transitions (state machine: pending → confirmed/failed/expired, terminal states absorb late duplicates). 6. Ticket Service consumes `TicketIssued`, generates signed QR/PDF, stores in S3 + DynamoDB; Notification Service emails user. ### Expiration - Primary: Redis TTL expires the `hold:*` key → keyspace notification triggers expiration worker; worker runs Aurora transaction releasing seats only if reservation still `pending_payment` (CAS on state). - Backstop: scheduled job every 30s scans `reservations WHERE state='pending_payment' AND expires_at < now() - 30s` and releases. Late webhook arriving after expiration: if seat already resold, mark payment as `refund_required` and trigger automatic refund; if seat still free, optionally re-confirm — but default policy is refund, because we cannot re-hold a possibly-resold seat. Payment provider's 5-min delay is within the 10-min hold window, so normal case has no conflict. ## 7. Preventing Overselling (Consistency) - Seat is a single owned resource: every state transition uses **optimistic concurrency** in Aurora (`WHERE status=expected_status AND version=expected_version`). - Redis SETNX provides fast first-line rejection at 8k RPS without hammering the DB; Aurora row-update is the second line and the legal truth. - All payment-side writes are idempotent via `provider_ref` uniqueness + DynamoDB dedupe table. - Outbox pattern ensures domain events are published exactly-once to Kafka relative to DB commits. - Strong consistency within a single seat row; eventual consistency is acceptable only for aggregate availability counts shown in browse views. ## 8. Scaling Strategy for Spikes - **Virtual waiting room**: when `concurrent_users > threshold`, new users get a queue token; only N tokens/sec are admitted to the reservation endpoints. Keeps the system at known capacity (e.g., admit 10k/sec to absorb 8k reservation attempts/sec). - **Horizontal autoscaling** (HPA on EKS) on CPU and custom RPS metrics; pre-warm pods 15 minutes before announced on-sales. - **Sharding hot events**: partition Redis keys by `event_id` so a single mega-event lands on a dedicated shard; can pre-provision shards for known on-sales. - **Read scaling**: Aurora read replicas + Redis for availability + CDN for seat-map static data. - **Backpressure**: API Gateway request quotas per user; 429 with Retry-After. - **Async fan-out**: Kafka decouples ticket generation, email, analytics from the hot path. - **Connection pooling**: RDS Proxy / PgBouncer to avoid Aurora connection storms. - **Bot defense**: WAF, CAPTCHA on `POST /reservations` during on-sales, device fingerprinting. ## 9. Reliability & Disaster Recovery - Multi-AZ for every stateful component (Aurora, Redis with replicas + automatic failover, MSK RF=3, DynamoDB). - Aurora: continuous backup to S3, PITR to any second within retention → RPO ≤ 1 min met; failover ~30–60s → RTO ≤ 15 min met. - Redis: Multi-AZ with automatic failover; data is reconstructable from Aurora (holds can be rebuilt on cold start from `reservations WHERE state='pending_payment'`). - Kafka: tiered storage, RF=3, min ISR=2. - DR runbook: cross-region Aurora Global Database replica (RPO ~ seconds) for region-wide failure recovery; documented promotion procedure. - Chaos drills: AZ blackout, Redis primary kill, payment provider outage simulation quarterly. - Health checks at ALB level; circuit breakers (Resilience4j-like) between services and toward payment provider. - Graceful degradation: if Redis unavailable, fall back to DB-only path with stricter rate limit; if payment provider down, queue checkouts and notify user. ## 10. Monitoring & Alerting - **Metrics (Prometheus + CloudWatch)**: RPS, p50/p95/p99 latency per endpoint, reservation success rate, hold-acquire conflict rate, payment webhook lag, expiration worker lag, Aurora replica lag, Redis CPU/memory/evictions, Kafka consumer lag. - **SLOs**: 99.95% availability on-sale window; p95 browse < 300 ms; p95 reservation < 800 ms; error budget burn alerts. - **Tracing**: OpenTelemetry end-to-end (client → API → service → DB). - **Logging**: structured JSON to CloudWatch/Elastic; correlation IDs. - **Business dashboards**: holds/sec, conversion (hold→paid), oversell counter (must be 0 — page on any nonzero). - **Alerts**: oversell=0 violation (P0), webhook backlog > 1 min, reservation p95 > 800 ms for 5 min, Aurora failover, Redis failover, payment success rate drop > 2σ. ## 11. Key Trade-offs and Alternatives - **Redis as hold authority vs. DB-only**: pure DB approach is simpler and stronger but couldn't sustain 8k RPS on single-row hotspots; Redis-first absorbs the spike, DB row update guarantees correctness. - **Pessimistic locks (SELECT FOR UPDATE)**: considered; rejected because lock contention on popular sections would tank throughput. Optimistic locking with retries scales better. - **Reserved seating vs. general admission counter**: design above is per-seat. For GA, a single decrementing counter (`DECR` in Redis with floor 0, mirrored to DB) is used instead. - **Single-region vs. multi-region active-active**: constraint says one region. Active-active would complicate "never oversell" (cross-region consensus needed). We use cross-region read replica for DR only. - **Kafka vs. SQS**: Kafka chosen for ordered, replayable event log (helps with out-of-order payment processing and rebuilding state). - **Synchronous payment vs. webhook-only**: webhook-only chosen to remain PCI-light and tolerate provider latency; webhook delays up to 5 min still fit within 10-min hold. - **Waiting room vs. pure autoscaling**: autoscaling alone cannot protect downstream stateful stores; the queue gives deterministic load shape and a better UX than mass 503s. - **Issuing tickets synchronously vs. async**: async via Kafka keeps payment callback handler fast and resilient; user sees ticket within seconds via push/refresh. This design meets the stated SLOs, prevents overselling via layered optimistic concurrency, absorbs on-sale spikes via virtual queue + Redis-fronted holds, and satisfies the RPO/RTO targets through Multi-AZ managed stores with PITR and rehearsed 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.