Fronty a asynchronní zpracování v ecommerce

Zákazník klikne na „Objednat“. V tu chvíli se má objednávka zapsat do ERP, odečíst ze skladu, vystavit faktura, založit zásilka u dopravce, odeslat e-mail a propsat stav na marketplace. Když to všechno běží synchronně, stačí, aby jeden systém odpovídal pomalu, a zákazník čeká. Když jeden spadne, objednávka se zasekne nebo se ztratí.

Fronty zpráv tenhle problém řeší. E-shop jen uloží zprávu „nová objednávka“ a zákazníkovi hned potvrdí nákup. Zbytek se zpracuje na pozadí, a když ERP zrovna neodpovídá, zpráva počká. V článku ukážeme, jak fronty v ecommerce navrhujeme, které nástroje se používají a kde se nejčastěji chybuje.

Synchronně, nebo asynchronně

Synchronní zpracování znamená, že volající čeká na výsledek. Asynchronní znamená, že úlohu předá a pokračuje dál. Obojí má své místo.

Pravidlo, které používáme: synchronně jen to, bez čeho zákazník nemůže pokračovat. Všechno ostatní je kandidát na frontu.

Jaké nástroje se používají

Podrobné srovnání najdete ve znalostní bázi v hesle Message queues. Pro e-shop se nejčastěji rozhodujeme mezi třemi možnostmi:

• RabbitMQ. Open source broker s bohatým směrováním zpráv. Provozujete ho sami nebo jako spravovanou službu. Hodí se pro middleware mezi e-shopem, ERP, skladem a marketplace.
• Amazon SQS. Plně spravovaná fronta v AWS. Neřešíte servery, platíte za požadavky. Podle ceníku AWS je 1 milion požadavků měsíčně zdarma, pak standardní fronty stojí 0,40 USD a FIFO fronty 0,50 USD za milion požadavků (region US East, k 9/2026; aktuální ceník ověřte u poskytovatele).
• Redis s BullMQ. Knihovna pro fronty úloh v Node.js nad Redisem. Rychlé nasazení pro úlohy na pozadí v menších a středních aplikacích.

Pro velké objemy událostí a více nezávislých odběratelů se používá i Apache Kafka. U typického českého e-shopu je to ale většinou zbytečně těžký nástroj.

Doručení aspoň jednou a idempotence

Nejdůležitější věc, kterou si o frontách zapamatovat: zpráva může přijít víckrát. Standardní fronty Amazon SQS to v dokumentaci uvádějí výslovně, stejně jako to, že pořadí není zaručené. RabbitMQ zprávu doručí znovu, když konzument spadne dřív, než ji potvrdí. Tomuto chování se říká doručení aspoň jednou (at-least-once).

Důsledek: zpracování musí být idempotentní. Druhé zpracování stejné zprávy nesmí nic pokazit.

Jak to řešíme v praxi:

• Každá zpráva nese jedinečné ID, typicky ID objednávky nebo události.
• Konzument si zpracovaná ID ukládá a před zápisem kontroluje, jestli už zprávu neviděl.
• Kde to jde, používáme operace, které jsou idempotentní samy od sebe: „nastav sklad na 12“ místo „odečti 1“.
• U volání cizích API posíláme idempotentní klíč, pokud to API podporuje.

FIFO fronty v SQS nabízejí deduplikaci: zprávu se stejným deduplikačním ID během pětiminutového intervalu nedoručí znovu. To pomáhá, ale nenahrazuje idempotentního konzumenta. Duplicita může vzniknout i jinde než ve frontě.

Opakování a dead-letter queue

Zpracování selže. ERP vrátí chybu, API dopravce odpoví limitem požadavků, data jsou neúplná. Fronta proto zprávu nabídne znovu. Aby opakování nezahltilo systém, který má problém, prodlužuje se odstup mezi pokusy (exponential backoff). BullMQ to nastavuje počtem pokusů (attempts) a typem odstupu: u exponenciálního je prodleva 2^(pokus−1) × delay.

Zpráva, která selže opakovaně, patří do dead-letter queue (DLQ). Tam čeká na prozkoumání a po opravě se pošle zpět.

Pozor na RabbitMQ: pokud quorum fronta nemá nastavený dead letter exchange, zpráva se po překročení limitu doručení zahodí. Dokumentace RabbitMQ proto doporučuje dead lettering nastavit u všech quorum front.

Rozlišujte chyby dočasné a trvalé. Výpadek ERP je dočasný a opakování pomůže. Neexistující kód produktu je trvalý a opakování jen oddálí nevyhnutelné. Takovou zprávu je lepší poslat do DLQ hned.

Past zvaná dvojí zápis

Klasická chyba: aplikace uloží objednávku do databáze a pak pošle zprávu do fronty. Co když aplikace spadne mezi těmito dvěma kroky? Objednávka existuje, ale ERP se o ní nikdy nedozví. Nebo obráceně: zpráva odešla, ale zápis do databáze selhal.

Řešením je vzor transactional outbox. Zprávu uložíte do tabulky „outbox“ ve stejné databázové transakci jako objednávku. Samostatný proces pak zprávy z outboxu čte a publikuje do fronty. Buď se uloží obojí, nebo nic. Protože i tento proces může zprávu odeslat dvakrát, idempotence na straně konzumenta je potřeba i tady.

Monitoring: fronta nesmí tiše růst

Fronta skryje problém, ale nevyřeší ho. Když konzument přestane zpracovávat, zprávy se hromadí a nikdo si toho nevšimne, dokud nezavolá zákazník, že mu nepřišla faktura. Minimum, které sledujeme:

• délka fronty a stáří nejstarší zprávy,
• počet zpráv v DLQ (každá zpráva tam je signál k akci),
• počet chyb a opakování za hodinu,
• dostupnost konzumentů.

Na každou z těchto metrik nastavujeme upozornění. Víc o dohledu v článku Monitoring integrací: jak se dozvědět o chybě dřív než zákazník.

Kdy frontu nepotřebujete

Fronta je další infrastruktura, kterou je třeba provozovat. Pro malý e-shop s jednou integrací je často zbytečná. Tam stačí cron, který jednou za pár minut synchronizuje změny, nebo webhook s opakováním. Srovnání najdete v článku Cron joby vs. realtime: kdy použít co.

Checklist před nasazením

1. Víte, které kroky musí být synchronní a které mohou počkat.
2. Každá zpráva má jedinečné ID a konzument je idempotentní.
3. Zprávy se do fronty dostávají přes outbox, ne dvojím zápisem.
4. Je nastavený počet pokusů a rostoucí odstup mezi nimi.
5. Existuje DLQ a postup, kdo a jak ji zpracuje.
6. Trvalé chyby jdou do DLQ bez zbytečného opakování.
7. Sledujete délku fronty, stáří zpráv a obsah DLQ s upozorněním.

Asynchronní integrace navrhujeme a stavíme v rámci služeb API a microservices a integrace. Typicky jako součást napojení na ERP, sklad nebo marketplace. Pokud řešíte právě ERP, začněte článkem Napojení e-shopu na ERP: kdy a jak. Cenu připravíme po konzultaci podle rozsahu.