Ugrás a tartalomhoz
← Vissza a blogra

Szezonális csúcsterhelés uszodában

Egy strandüszoda 15× terhelési arányt él. A 2026 májusi hőhullámkor 3200 belépés egy nap. Capacity dashboard + waitlist + BullMQ + connection pool tuning.

Szezonális csúcsterhelés uszodában

Egy strandüszoda nem egyenletesen terhelt. Júniustól augusztusig 4–6× annyi vendéget szolgál ki, mint a téli hónapokban. 2026 májusában egy hőhullám egyetlen szombaton 3200 belépést hozott egy uszodához, amely átlagosan 800-at szokott. Ez a cikk arról szól, hogy a Lunda hogy bírta el.

A terhelési profil

Egy közepes méretű strandüszoda 2025-ös éves adatai:

  • Január–április — napi átlag 250–400 belépés, hétvégén 600-ig felmegy.
  • Május — átmenet, 400–800 / nap, az időjárástól függően.
  • Június–augusztus — átlag 1200–1800 / nap, csúcsszombatokon 2500–3500.
  • Szeptember–december — visszaesés 200–500 / nap-ra.

A peak-to-trough arány tehát kb. 1:15. Egy rendszernek, ami januárban 250 vendéget bír el problémamentesen, augusztusban 15× annyit kell tudnia ugyanazzal a UX-szel.

A 2026. május 16-i szombat

Május 16-án hőhullám érkezett: 34°C-os szombat. Az egyik vidéki strandüszoda ügyfelünk reggel 9-re már 800 vendég, délben 2100, este 21:00-ig 3200 belépés. Az átlag májusi szombat 800.

Mit csinált a rendszer:

  • A POS válaszidő végig 100–180 ms között maradt (cél: <200 ms). Nem volt UX-degradáció.
  • A beléptető kapuk sub-300 ms-ban maradtak — a 6 kapu összesen 8400+ belépést szolgált ki a nap folyamán.
  • 1 incidens: 16:42-kor egy 3 perces backend-lassulás (Postgres query queue megtelt). A capacity dashboard riasztott, a DevOps figyelte, magától visszaállt.
  • A capacity dashboard egyszer 14:00-kor jelezte "95% kapacitás" — a recepciós kézzel be tudta kapcsolni a waitlist módot 12 percre, ezalatt 47 vendég lett a várólistán.

Végeredmény: 3200 belépés, 0 vendég-panasz a rendszerről (csak a hőség miatt).

A capacity dashboard

Minden Lunda admin felület része egy live capacity dashboard. Mutatja:

  • Aktuális belépésszám — hányan vannak bent most.
  • Belépés / kilépés ráta — utolsó 15 percre.
  • Becsült telítettség — a létesítmény engedélyezett max. kapacitásához viszonyítva.
  • Sor a kapuknál — a turnstile-szenzorok alapján becsült várakozó.
  • Waitlist státusz — be van-e kapcsolva, hányan vannak rajta.

A dashboard 5 másodperces auto-refresh-sel megy, a recepciós és az üzemeltetés folyamatosan látja.

A waitlist mód

Amikor a létesítmény eléri a 95%-os telítettséget, az üzemeltetés bekapcsolja a waitlist módot. Ettől kezdve:

  • Új vendég nem mehet be azonnal, hanem felkerül egy listára (telefonszámmal vagy a Lunda app-fiókkal azonosítva).
  • Amikor valaki kimegy, az első várakozó SMS-ben értesítést kap: "Mehet, 15 percen belül érkezzen".
  • Ha 15 percen belül nem érkezik, a következő vendég jön.

A waitlist alapból kikapcsolva. Csak akkor kapcsolódik be, ha az üzemeltetés engedi. A 2026. május 16-i szombaton 12 percig volt aktív, 47 vendég iratkozott fel, 41 vissza is jött.

Az infrastruktúra-tuning

A terhelési csúcsra a Lunda három területen tuningolt:

  1. BullMQ háttér-feladatok — a nem-kritikus műveletek (számlanyomtatás, NTAK-feladás, e-mail küldés) BullMQ-ba mennek, nem a kritikus path-ra. Csúcsidőben a queue 800 jobbal is megtelhet, este lassan üríti.
  2. Postgres connection pool — alapból 20 connection / node, csúcsidőre 60-ra emeltük. Ez 3 node-on 180 párhuzamos connection.
  3. Read replica a riportokhoz — az admin riportok (kasszariport, NTAK riport, bérlet-analitika) olvasási replikára mennek, nem terhelik a master DB-t. A pénztári tranzakciókhoz csak a master kell.

Tanulság

A szezonális csúcs nem váratlan, hanem előrelátható — minden évben jön, és minden évben más a maximum. A Lunda úgy van építve, hogy a 15× terhelést problémamentesen elbírja. A 2026. május 16-i szombat ezt bizonyította: 3200 belépés, 0 panasz, 1 másodperces incidens.

Beszéljünk a projektedről

Mondd el, mit építesz — meglátjuk, hogyan segíthetünk.