Návrh systému rezervace lístků

Architektura systému rezervace vstupenek: od API po škálování

Systém rezervace vstupenek musí umožňovat prohlížení akcí, vyhledávání podle parametrů a spolehlivé rezervování bez dvojitého prodeje. Zaměřuje se na dostupnost dat při čtení a přísnou konzistenci při zápisu. Očekávaná zátěž — až 10 milionů uživatelů na populární událost, zpoždění vyhledávání pod 500 ms, poměr čtení k zápisu 100:1.

Klíčové entity: Event (akce s datem, popisem, typem), User (uživatel), Performer (umělec), Venue (místo konání s mapou míst), Ticket (vstupenka s místem, cenou, stavem), Booking (rezervace se seznamem vstupenek a stavem).

Návrh API endpointů

API je postaveno kolem tří prioritních funkcí. Začínáme jednoduchými endpointy, které upřesňujeme během návrhu.

Prohlížení akce:

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

Vrací podrobnosti události, místa konání, umělce a seznam vstupenek pro vykreslení mapy míst na klientovi.

Vyhledávání:

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

Filtrace podle klíčových slov, dat, stránkování pro vysokou propustnost.

Rezervace (počáteční verze):

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

Později rozdělujeme na rezervaci a potvrzení pro transakční spolehlivost.

Architektura na vysoké úrovni

Komponenty systému

• API Gateway: směrování, autentizace, omezení rychlosti, logování.
• Event Service: čtení dat o akcích, místech konání, umělcích z databáze.
• Search Service: zpracování vyhledávacích dotazů s filtrací.
• Booking Service: správa rezervací s transakcemi.
• Databáze: PostgreSQL pro ACID transakce (Bookings, Tickets), NoSQL nebo cache pro čtení (Events, Venues).

Tok prohlížení: klient → Gateway → Event Service → databáze → odpověď s mapou míst.

Škálování pod zátěží

Pro 10 milionů DAU na událost používáme:

• Cacheování: Redis pro častá čtení (akce, vyhledávání).
• Škálování horizontální: podle eventId v Tickets/Bookings.
• CQRS: oddělení čtení (read repliky) a zápisu (master).
• Load Balancer: distribuce provozu mezi služby.

Poměr 100:1 čtení/zápis určuje prioritu read replik a CDN pro statická data (mapy míst).

Detaily rezervace a konzistence

Kritická oblast — vyhnutí se dvojí rezervaci. PostgreSQL s transakcemi a izolací Serializable nebo Optimistic Concurrency Control (OCC) na verzi vstupenky.

Proces:

• Klient vybere ticketIds.
• Booking Service spustí transakci: SELECT FOR UPDATE na Tickets.
• Kontrola stavu (available), aktualizace na reserved.
• Vytvoření záznamu Booking.
• Potvrzení platby → stav confirmed.

Příklad tabulky Tickets:

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

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

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

OCC: při UPDATE kontrolujeme version, reject při konfliktu.

Pro vysokou konkurenci — dočasné rezervace (TTL 10 min) v Redis.

Optimalizace vyhledávání

Základní SQL filtr se neškáluje na 10 milionů. Přecházíme k:

• Elasticsearch pro fulltextové vyhledávání podle keyword, performer, venue.
• Indexace Events s poli: name, date_range, location.
• Fasetové vyhledávání pro filtry (datum, typ).

Tok: Search Service → ES dotaz → agregace → cache v Redis.

Zpoždění <500 ms je dosaženo přednačtením populárních akcí.

Hloubkové zkoumání škálovatelnosti

Databáze

• Master PostgreSQL (Bookings, Tickets) — horizontálně škálováno podle eventId.
• Read Repliky — 10+ pro prohlížení Events.
• Redis — session, dočasné rezervace, top akce.
• Elasticsearch — vyhledávání, analytika.

Migrace dat: Event Service zapisuje do Kafka → CDC → repliky/ES.

Monitorování a odolnost proti selhání

• Circuit Breakers ve službách.
• Health checks, auto-scaling.
• Zálohy: WAL archivace v S3.

Co je důležité

• Přísná konzistence pouze v Booking transakcích, eventual consistency pro vyhledávání.
• OCC + dočasné zámky v Redis zabraňují 99 % konfliktů bez blokování.
• CQRS/ES zajišťují <500 ms vyhledávání při zátěži 100:1.
• Horizontální škálování podle eventId škáluje na 10M+ DAU.
• API Gateway centralizuje security a throttling.

— Editorial Team