Kapacitáskezelés szezoncsúcsra — 200 foglalás/nap és 99,7% uptime

Kapacitáskezelés szezoncsúcsra — 200 foglalás/nap és 99,7% uptime

Az utazási iroda szoftvere nem egyenletesen terhelt. Egy magyar iroda éves grafikonján a következő minta látszik: márciustól májusig + szeptembertől októberig napi ~200 foglalás, a többi 8 hónapban napi ~20. Ez a 10x-es lengés a rendszer architektúrájának valós próbája.

A szezoncsúcs anatómiája

2026 április–májusi adatok a Travelium teljes ügyfélbázisán:

• 6 hét csúcs (március 21 – május 6)
• 14 800 foglalás ezen időszakban
• napi átlag: 215 foglalás, csúcsnap 312
• csúcsóra: 17:00–19:00 (a látogatók munka után intéznek)
• rendszer uptime: 99,7% (kb. 30 percnyi cumulatív leállás az időszakra)
• lecsengés: május 7-től napi ~25 foglalás

A 8x ugrást két perc alatt nem lehet skálázni. Tudatos felkészítést igényel.

Beszállítói API rate limiting

A legnagyobb veszély nem a saját rendszerünk — hanem a beszállítóké. Amadeus alapvető limitje 30 hívás/másodperc/iroda. Ha túllépjük, 5 percre tiltanak. Egy csúcsóra alatt ez 1500 elveszett keresést jelent.

A megoldás a Travelium oldalán: per-beszállító, per-iroda token bucket. Minden beszállító kap egy konfigurált limit-et (Amadeus: 25 hív/s, Sabre: 40, direkt szállodai API-k változó). A bucket Redis-ben él, atomikus INCR + TTL workflow-val.

Ha egy iroda túllépné a saját limit-et, a kérés 429-cel visszakerül a UI-ra, az ügynök egy diszkrét toast-üzenetet lát: „Egyidejű keresések magas terhelése, próbálja újra 3 másodperc múlva.” Egy ügynökre nézve évente átlag 4-szer fordul elő — elviselhető.

BullMQ-háttér prioritással

A háttérmunkák (voucher generálás, számla kiállítás, email küldés, beszállító állapot-szinkron) BullMQ + Redis queueban futnak, három prioritási sávval:

1. high — ügyfél-blokkoló dolog: fizetés visszaigazolása, voucher generálás. Cél: < 5 mp.
2. normal — háttér: review-email küldése, statisztika-aggregálás. Cél: < 5 perc.
3. low — opcionális: havi riport generálás, partner-szinkron. Cél: < 60 perc.

Csúcsidőben a queue mélysége a normal sávban tipikusan 800–1200 között mozog, de a high mindig 0 közelében marad. A 99,7% uptime nem a hardver — a queue-prioritás eredménye.

Pre-warming cache

A népszerű csomagok kereső-cache-ét a szezon előtt 4 héttel elkezdjük előmelegíteni. A cache-warmer cronjob óránként végigfut a top 200 desztináció + dátum kombináción, és előre lekér mindent a beszállítóktól.

Ez a tehet ár: szezoncsúcsban az átlagos „keresés-válasz” idő 2,1 másodperc (warm cache hit), nem 5,5 másodperc (cold lookup). A különbség a látogató oldalán érzékelhető — kevesebb türelmetlen bounce.

A 2026 áprilisi crunch

És az igazi vizsga. Április 8., egy keddi nap, 17:42-kor 312 párhuzamos keresés. A rendszer-metriák:

• API válaszidő p95: 2,8 mp (cél: < 3 mp ✅)
• DB connection pool használat: 78% (max: 100, ✅)
• Redis memória: 4,1 GB / 8 GB allokált (✅)
• Beszállítói 429-ek: 8 (Amadeus, 30 másodpercen belül recovered, ✅)
• Sikertelen foglalás: 0 (✅)

Ez az óra termelte a hónap legnagyobb forgalmát egy 14 fős magyar iroda számára: 41 sikeres foglalás, 11,2 millió Ft GMV. Egyetlen ügyfél sem látott „rendszerünk átmenetileg túlterhelt” hibát.

Lesson

A szezoncsúcs nem hardver-vásárlás. Token-bucket alapú rate limiting, BullMQ-prioritás, cache-előmelegítés és per-pillanat metrika-figyelés együttesen adja a 8x-es lengés elviseléséhez szükséges architektúrát. A 99,7% uptime egy 14 fős iroda mögött ugyanaz, mint egy nagy OTA-é — csak két nagyságrenddel olcsóbb mérnöki munkából.