Dinamikus csomagolás — szállodák és járatok valós időben
A klasszikus utazási csomag statikus volt: katalógus, szezonkönyv, fix árak. A dinamikus csomagolás ezzel szakít: az ügynök valós időben kérdez le járatot és szállodát, a rendszer összerakja a csomagot, kalkulál margint, és kiteszi az ügyfél elé. A különbség egy 80 ezres és egy 110 ezres ajánlat között gyakran 12 másodperc megfelelő szoftverrel.
Architektúra: 3 GDS + 12 direkt szállodai API
A Travelium beszállítói rétege jelenleg három GDS-t (Amadeus, Sabre, Travelport) és 12 direkt szállodai API-t kérdez egy keresésre. A futtatás párhuzamos: a 15 hívás egyszerre indul, és amit visszakapunk az első 2,5 másodpercben, azt megjelenítjük. Ami később jön, az „új találat” jelölésű ikont kap.
Ez a megközelítés tudatos: a teljes 15-ből 1–2 partner mindig lassan (3–6 mp) vagy egyáltalán nem válaszol. Ha mindenkit megvárnánk, az iroda kereső UI-ja 6 másodperces lenne — versenyképtelen.
Ár és kapacitás merge
A legkényesebb logika: ugyanaz a szálloda 4 csatornán is visszajöhet (saját API + 2 GDS + egy bedside) különböző árral és kapacitással. A merge-szabályok:
- Kapacitás unió, ár minimum. Ha bármelyik csatornán van szabad szoba és ár, a csomag eladható; az ügynök a legolcsóbb ajánlatot látja először.
- Forrás-cimke látható. Az ár mellett ott van a forrás (
AM= Amadeus,DRT= direkt). A 4%-os jutalék-különbségek itt jönnek ki. - Margin-kalkulátor. Az ügynök egy csúszkával adja meg a markup-ot (15–35%), a rendszer azonnal mutatja a végső eladási árat és a saját jutalékot.
A fallback, amikor egy beszállító leáll
Március 12-én az Amadeus 47 percig nem válaszolt EU-zónában. A Travelium ezeket a hívásokat 8 másodperc után megszakítja, megjelöli a beszállítót DEGRADED státuszra, és 60 másodpercig nem hívja újra (circuit breaker). Az ügynök UI-ban egy diszkrét sárga sáv jelez: „Amadeus átmenetileg elérhetetlen, 11 másik forrás aktív.”
Igy a 47 perces leállás alatt is mentek a foglalások — Sabre-ből, Travelportból és a direkt szállodai API-kból. Egyetlen ügyfél sem kapott üres találati listát.
A bug, amit megettünk
És a legrosszabb pillanat. Április 3-án, péntek hajnal 4:00 és déli 12:00 között a cache-réteg régi árakat szolgált fel: egy szálloda 8 órán át 38 ezerért jelent meg, miközben a beszállítónál már 52 ezer volt. 23 csomag ment ki rossz áron, ~340 ezer Ft veszteség.
A root cause: a cache-invalidálás setTimeout-ra épült és a Node.js process az éjszakai restart után új process-ben indult — a timer elveszett, az invalidálás nem futott le. A fix BullMQ + Redis alapú TTL-keymanagement; a setTimeout mintha sosem létezett volna a kódban.
Operatív részletek a napi munkából
Egy átlagos ügynöki nap a Travelium dinamikus csomagolásával: reggel 9-kor az iroda 4 ügynöke párhuzamosan dolgozik, mindegyik átlagosan 18 keresést futtat óránként. Ez 72 párhuzamos keresés egyetlen kis irodából — és ebből a 15 beszállítói API-n 1080 hívás per óra. A token-bucket itt is dolgozik a háttérben, hogy senki ne lépje át a per-beszállító limitet.
A merge-réteg ezekre a párhuzamos keresésekre 220 ms átlagos válaszidőt produkál (az utolsó beszállító válaszára várás nélkül). A teljes UI-renderhez (kereső → eredménylista) az átlagos time-to-first-result 1,8 másodperc, a time-to-interactive 3,2 másodperc.
A margin-kalkulátor csúszkájának finomítása külön történet: 4 hónapig 0,1%-os granularitással engedtük állítani, az ügynökök 92%-ban kerek 5%-os értékeket választottak. Egyszerűsítettünk 1%-os léptékre — a UI fele lett, a használati gyakoriság ugyanannyi maradt.
Lesson
A dinamikus csomagolás nem egy beszállítóhoz beillesztett API. Hanem fan-out hívás, intelligens merge, circuit breaker, margin-csúszka, és — legtöbbször a legnehezebb — egy cache-réteg, ami soha nem felejt el lejárni.