Miért RabbitMQ és nem BullMQ a Logistics Flow-ban
Minden más Nortinia terméknél BullMQ a sorbaállító. A logisztikánál mégis RabbitMQ nyert. Elmondjuk, miért.
A queue választás soha nem technológiai kérdés — hanem az, hogy ki lesz a felelős, ha üzenet vész el.
A Netorigo stack alapértelmezésben BullMQ-t használ: a Redis már ott van, a fejlesztő ismeri, és a legtöbb feladathoz bőven elég. Mégis a Logistics Flow (a netorigo-app-logistics repo) elkapta a kivételt és RabbitMQ-ra váltott. Ez nem "jobb technológia" kérdése volt, hanem három konkrét ok.
Ok 1: topikalapú routing
Egy shipping event (pl. shipment.created.hu.budapest) hét különböző fogyasztóhoz kerül: customs, raktár, flotta, számlázás, ügyfélértesítés, analitika, audit. A RabbitMQ topic exchange ezt egy publish-ban megcsinálja — a BullMQ-val ugyanez 7 külön queue-t és 7 külön írást jelentene.
Ok 2: dead letter queue mint first-class citizen
- A logisztikai eventek ~1%-ban validációs hibát produkálnak
- Ezek nem eldobható üzenetek — minden egyes shipment egy valós rakomány
- A RabbitMQ DLQ beépítve van, és UI-ból újrajátszható
- A BullMQ-ban a retry és a failed state keveredik, nehezebb kezelni
- A csapat humán felelőse mindennap átnézi a DLQ-t
Ok 3: queue depth monitoring
A RabbitMQ natív metrikákat exportál Prometheus-ba: queue depth, publish rate, consumer count, ack rate. A Grafana dashboard-ról egyetlen kattintással látszik, hogy melyik consumer lassít. Ezt a BullMQ-val kézzel kellett volna kialakítani, és a raktári csapat 4 héttel később lett volna éles vele.
A tanulság: ne válassz queue-t technikai védekezés alapján. Válassz aszerint, hogy ki lesz felelős, ha üzenet eltűnik. A RabbitMQ-nál ez a felelősség egyértelműbb.
Amit a migráció után tanultunk
- A RabbitMQ memória-limitjét mindig konfiguráld — különben egy elszállt consumer betömi a brokert
- A publisher confirm alapértelmezésben ki van kapcsolva; kapcsold be, különben nem garantált az elküldés
- A queue deklarációt tartsd kódban (kódbázisban), ne UI-ból kattintva — különben DR esetén nincs meg
- A Grafana dashboardot az üzemeltető is használja, ne csak a dev — jobb SLA érzés
- Két különböző környezet (stage + prod) különböző vhost-on fusson, sose ugyanabban
És egy másik dolog, amit érdemes elmondani: a BullMQ nem tűnt el a logistics repo-ból. A rövid, könnyű feladatokra (email küldés, cron trigger, cache warm-up) továbbra is BullMQ fut. A RabbitMQ csak a valódi, üzleti eventek útvonala. A kettő különbsége a helyes használatban van — és nem egyik "jobb" a másiknál.