Message queues
Aktualizováno 22. 9. 2026
Fronta zpráv (message queue) je prostředník, do kterého jedna část systému ukládá úlohy a druhá je postupně zpracovává. Odděluje příjem události od její obsluhy a chrání před výpadky a špičkami.
Rychlá fakta
- Typ
- architektonický vzor a infrastrukturní software pro asynchronní zpracování
- Cena
- open-source nástroje (RabbitMQ, Kafka, BullMQ) zdarma, platíte provoz; Amazon SQS 1 milion požadavků měsíčně zdarma, pak 0,40 $ za milion u standardních front (ceník k 9/2026, aktuální ceník ověřte u poskytovatele)
- Časová náročnost zavedení
- řádově dny (jedna fronta pro konkrétní proces) až týdny (přestavba integrací na asynchronní model)
- Náročnost zavedení
- střední až vysoká — samotná fronta je jednoduchá, náročné je správné opakování, idempotence a monitoring
- Vhodné pro
- e-shopy s více integracemi, špičkami provozu a procesy, které nesmí ztratit data
Co to je
Fronta zpráv je vyrovnávací paměť mezi tím, kdo práci zadává (producent), a tím, kdo ji vykonává (konzument). Producent zprávu uloží a pokračuje dál. Konzument si ji vyzvedne, až má kapacitu.
Příklad z e-shopu: zákazník dokončí objednávku. E-shop nečeká, až se objednávka zapíše do ERP, vystaví se faktura a odešle zásilka dopravci. Jen vloží zprávu „nová objednávka" do fronty a zákazníkovi hned ukáže potvrzení. Když ERP zrovna neodpovídá, zpráva ve frontě počká a zpracuje se později.
Jak to funguje
Nejpoužívanější nástroje:
| Nástroj | Model | Kdy se hodí |
|---|---|---|
| RabbitMQ | klasický broker, zpráva se po potvrzení smaže | úlohy a události mezi službami, směrování zpráv |
| Apache Kafka | log událostí, zprávy zůstávají podle retence | velké objemy, více nezávislých odběratelů, přehrání historie |
| Amazon SQS | spravovaná fronta v AWS | cloudové aplikace bez vlastní správy serverů |
| Redis + BullMQ | knihovna pro fronty úloh v Node.js | úlohy na pozadí v menších a středních aplikacích |
Rozdíl mezi RabbitMQ a Kafkou je podstatný. RabbitMQ zprávu po potvrzení konzumentem odstraní. Kafka zprávy ukládá do logu a drží je podle nastavené doby nebo velikosti. Každá skupina konzumentů si pamatuje, kam až dočetla, a víc skupin může číst stejná data nezávisle.
At-least-once. Většina front garantuje doručení aspoň jednou. Standardní fronty Amazon SQS výslovně uvádějí, že stejná zpráva může přijít víckrát a v jiném pořadí. Fronty FIFO v SQS duplicity do fronty nezavádějí a drží pořadí v rámci skupiny zpráv.
Idempotence. Protože zpráva může přijít dvakrát, musí její zpracování snést opakování bez škody. Druhé zpracování stejné objednávky nesmí vytvořit druhou fakturu ani dvakrát odečíst sklad. Řešení: jedinečné ID zprávy nebo objednávky a kontrola „už zpracováno" před zápisem.
Opakování a dead-letter queue. Když zpracování selže, fronta zprávu nabídne znovu, ideálně s rostoucím odstupem (exponential backoff). BullMQ to umí nastavit počtem pokusů a typem odstupu. Zpráva, která selže opakovaně, se přesune do dead-letter queue (DLQ). V SQS to řídí parametr maxReceiveCount, v RabbitMQ dead letter exchange. Z DLQ se zprávy dají prozkoumat a po opravě znovu poslat.
Výhody a limity
Výhody
- Výpadek jednoho systému nezastaví ostatní. Zprávy počkají.
- Špička (Black Friday, velký import) se rozloží v čase.
- Pomalé kroky neblokují zákazníka ani administraci.
- Snadné přidání dalšího odběratele stejné události.
Limity
- Další infrastruktura, kterou je třeba provozovat a monitorovat.
- Zpracování není okamžité a ladění asynchronních chyb je náročnější.
- Bez idempotence vznikají duplicity, bez DLQ tiše mizí chybné zprávy.
- Pro malý e-shop s jednou integrací je to často zbytečně složité. Tam stačí cron nebo webhook s opakováním.
Checklist před nasazením fronty:
- Každá zpráva má jedinečné ID a konzument kontroluje duplicity.
- Je nastavený počet pokusů a odstup mezi nimi.
- Existuje DLQ a někdo dostane upozornění, když se plní.
- Sledujete délku fronty a stáří nejstarší zprávy.
Jak to řešíme v Převeďshopu
Fronty nasazujeme tam, kde e-shop propojuje víc systémů a ztráta nebo zdvojení dat by stály peníze. Typicky jako součást middleware mezi e-shopem, ERP, skladem a marketplace. Navrhneme vhodný nástroj podle objemu a infrastruktury, zajistíme idempotentní zpracování, DLQ a monitoring. Víc na stránkách API a microservices a Integrace a v článku Fronty a asynchronní zpracování v e-commerce. Cenu připravíme po konzultaci podle rozsahu.