Cron joby vs. realtime — kdy použít co

Každá integrace e-shopu dřív nebo později narazí na stejnou otázku: má se to dít hned, nebo stačí jednou za čas? Sklad z ERP, stav objednávky u dopravce, ceny od dodavatele, faktura do účetnictví. Odpověď rozhoduje o nákladech na vývoj, zátěži API i o tom, jestli zákazník koupí zboží, které už neexistuje.

Nejde o souboj starého a nového. Cron i realtime zpracování přes webhooky mají v e-shopu své místo. V tomhle článku ukážeme, podle čeho mezi nimi volíme, kde každý z přístupů selhává a proč v praxi skoro vždy stavíme kombinaci obou.

Dva přístupy v jedné větě

Cron job je úloha spouštěná podle času. Každých 15 minut stáhne feed dodavatele, každou noc přepočítá ceny, v pondělí ráno pošle report. Neptá se, jestli se něco změnilo. Prostě se v daný čas spustí.

Realtime znamená reakci na událost. Vznikne objednávka, e-shop pošle webhook a navazující systém ji hned zpracuje. Změní se sklad v ERP a změna se propíše do e-shopu během sekund. Nic se neděje, dokud se nic nestane.

Mezi nimi je ještě polling: častý cron, který se přes REST API ptá „je něco nového?“. Tváří se jako realtime, ale platí za to zbytečnými dotazy.

Srovnání v tabulce

Tabulka ukazuje hlavní pravidlo: cron je levný a snadno se kontroluje, realtime je rychlý, ale náročnější na provoz. Otázka tedy nezní „co je lepší“, ale „kolik stojí zpoždění“.

Kdy stačí cron

Cron volíme, když zpoždění nikoho nebolí, nebo když data stejně vznikají v dávkách.

• Feedy dodavatelů. Dodavatel generuje XML jednou za hodinu. Stahovat ho každou minutu nemá smysl.
• Exporty pro srovnávače a marketplace. Heureka, Zboží.cz nebo Google Merchant Center si feed stejně stahují ve vlastním intervalu.
• Přepočty a údržba. Cenotvorba podle marže, čištění košíků, generování sitemap, zálohy.
• Reporty a účetní exporty. Denní souhrn do účetnictví, týdenní přehled pro management.
• Velké objemy dat. Přenos celého katalogu je dávková práce z principu.

Pozor na jeden detail u WooCommerce. Vestavěný WP-Cron není skutečný cron. Podle dokumentace WordPressu se spouští jen při načtení stránky. Když naplánujete úlohu na 14:00 a do 17:00 nikdo nepřijde, poběží až v 17:00. Na provozních e-shopech proto WP-Cron vypínáme konstantou DISABLE_WP_CRON a wp-cron.php spouštíme systémovým plánovačem v pevném intervalu.

U velkých dat se vyplatí využít dávkové nástroje platformy. Shopify nabízí bulk operace v GraphQL Admin API: dotaz běží na straně Shopify na pozadí a výsledek dostanete jako soubor JSONL ke stažení (výsledky jsou dostupné sedm dní). Samotné provedení bulk dotazu se nezapočítává do běžných rate limitů. Shoptet má pro velké exporty asynchronní snapshot endpointy, které vrátí jobId a po dokončení pošlou webhook job:finished.

Kdy potřebujete realtime

Realtime se vyplatí tam, kde zpoždění stojí peníze nebo důvěru zákazníka.

• Nové objednávky. Čím dřív jsou v ERP a skladu, tím dřív se expedují. Shoptet k tomu nabízí webhook order:create.
• Sklad u rychloobrátkového zboží. Když se poslední kus prodá na marketplace, e-shop to musí vědět dřív, než ho koupí někdo další. Podrobněji v článku Realtime synchronizace skladu.
• Platby. Potvrzení platby z brány rozhoduje o tom, jestli se objednávka uvolní k expedici.
• Zákaznické notifikace. E-mail „zásilka je na cestě“ o den později ztrácí smysl.

Realtime má ale svou cenu. Příjem událostí musí být rychlý: Shoptet čeká na odpověď HTTP 200 nejvýš 4 sekundy, Shopify doporučuje odpovědět do 5 sekund (k 9/2026). Náročnější zpracování proto patří do fronty zpráv, ne přímo do obsluhy webhooku. A události mohou přijít dvakrát, takže zpracování musí být idempotentní. Detaily rozebíráme v článku Webhooky v ecommerce.

Proč realtime bez cronu nestačí

Webhook je notifikace, ne záruka. Platformy to otevřeně píšou:

Když váš server hodinu nejede, část událostí se ztratí. U WooCommerce navíc webhook po pěti chybách tiše přestane posílat cokoliv. Shopify proto v dokumentaci výslovně doporučuje stavět vedle webhooků kontrolní (reconciliation) úlohy, které chybějící data pravidelně dotáhnou přes API.

Z toho plyne vzor, který používáme u většiny integrací:

1. Webhook pro rychlost. Událost se přijme, uloží do fronty a potvrdí.
2. Fronta pro zpracování. Worker událost zpracuje, při chybě opakuje s rostoucím odstupem.
3. Cron pro jistotu. Jednou za interval se porovná stav v obou systémech a rozdíly se dorovnají.
4. Monitoring nad vším. Alert, když fronta roste, webhook přestane chodit nebo kontrolní úloha najde víc rozdílů než obvykle.

Kontrolní cron nemusí procházet všechno. Stačí změny od posledního běhu, například objednávky upravené za poslední dvě hodiny. Plná kontrola celého skladu jednou za noc je levná pojistka.

Na co si dát pozor u cronu

Cron vypadá jednoduše, ale v provozu má vlastní pasti.

• Překrývání běhů. Import trvá 20 minut, cron ho spouští každých 15. Dva běhy pak přepisují stejná data. Řešením je zámek, který druhý běh nepustí.
• Rate limity API. Dávka, která najednou pošle tisíce požadavků, narazí na limity. Shoptet povoluje nejvýš 3 souběžná spojení na jeden token a při překročení vrací HTTP 429 (k 9/2026). Dávka musí umět počkat a pokračovat.
• Tiché selhání. Úloha, která skončí chybou ve 3 ráno, nikoho nevzbudí. Bez alertu se na to přijde až z reklamací.
• Časová pásma a změna času. Úloha naplánovaná na 2:30 v noci při přechodu na letní čas buď neproběhne, nebo proběhne dvakrát. Plánujte mimo tuto hodinu.
• Rostoucí objem. Co dnes trvá 5 minut, bude při trojnásobném katalogu trvat 15. Hlídejte délku běhů.

Jak na to prakticky

Když navrhujeme integraci, projdeme pro každý datový tok tyto otázky:

• Kolik stojí hodina zpoždění? Pokud nic, stačí cron.
• Nabízí zdrojový systém webhooky pro tuhle událost? Pokud ne, realtime bude jen častý polling.
• Jak velký je jeden běh? Tisíce záznamů najednou patří do dávky.
• Co se stane, když se jedna událost ztratí? Pokud něco vážného, přidejte kontrolní cron.
• Kdo se dozví, že úloha neproběhla? Bez odpovědi na tuhle otázku integraci nespouštějte.

Tahle rozhodnutí děláme v rámci služby automatizace a při návrhu integrací s ERP, sklady a dodavateli. Pokud vám některá synchronizace běží pozdě, občas vynechá nebo nikdo neví, kdy naposledy proběhla, ozvěte se nám. Projdeme vaše toky a navrhneme, co nechat v dávce, co převést na události a kde chybí pojistka.