Skip to content

Projekt: Event-Plattform

Fullstack Advanced

Das lokale Kulturzentrum verzweifelt. Sie verkaufen Tickets noch per Excel-Liste und Email. Das führt zu Doppelbuchungen, Chaos am Einlass und genervten Gästen. Sie brauchen eine Echtzeit-Ticketing-Plattform.

Deine Rolle: System Architect & Lead Developer. Du löst ein Problem, das schon große Firmen (Ticketmaster) ins Schwitzen bringt: Concurrency (Gleichzeitigkeit).


Dieses Projekt ist technisch das anspruchsvollste.

Stell dir vor: Es gibt noch ein Ticket für das Konzert.

  • User A klickt “Kaufen”.
  • User B klickt “Kaufen” (eine Millisekunde später).
  • Beide sind im Checkout. Wer bekommt das Ticket?
  • Entscheidung: Wie löst du das? (Datenbank-Locks? Reservierungen mit Timeouts? Optimistic vs. Pessimistic Locking?)
  • Szenario: 500 Leute stehen vor der Tür. Der Einlass muss schnell gehen.
  • Aufgabe: Generiere fälschungssichere Tickets.
  • Frage: Was steckt im QR-Code? (Nur die ID? Ein signierter Token?) Und wie baust du den Scanner (Webcam-Zugriff im Browser)?

(Optional für Profis)

  • Wenn es Sitzplätze gibt: Wie speicherst du “Reihe 5, Platz 12”? Und wie zeigst du an, dass dieser Platz jetzt gerade von jemand anderem angesehen wird?

Das System muss robust sein:

  1. Konsistenz: Niemals mehr Tickets verkaufen als vorhanden sind.
  2. Verfügbarkeit: Der Admin muss jederzeit sehen: “Wie voll ist der Saal heute Abend?”
  3. Kommunikation: Tickets müssen automatisch per Mail versendet werden. (Integration von Mail-Diensten wie SendGrid/Resend).

EbeneFragen an dich
BackendPHP oder Node.js. Node.js ist oft stark bei Concurrency, aber auch PHP hat moderne Lösungen. Was wählst du und warum?
DatenbankTransaktionen (ACID) sind hier lebenswichtig. Welche Datenbank bietet dir die nötige Sicherheit und Performance?
RealtimeBrauchst du WebSockets, um Plätze auf der Seatmap live als “blockiert” anzuzeigen?

  1. Systemarchitektur: Wie verhindert man Daten-Inkohärenz in verteilten Systemen?
  2. Sicherheit: Wie verhindere ich, dass jemand Tickets fälscht oder sich Plätze erschleicht?
  3. Integrationen: Email-Versand, Payment-Mocking, Kamera-APIs.

  • Keep it ugly: Das Design ist zweitrangig. Die Logik “Ticketkauf” muss zu 100% sitzen.
  • Stress Test: Versuche, dein eigenes System kaputt zu machen. Öffne zwei Browser-Fenster und versuche, das letzte Ticket gleichzeitig zu kaufen.

Hast du eine Idee, wie du das “Race Condition” Problem löst? Erzähl uns von deinem Locking-Mechanismus!