Rozdíl mezi ptát se dokola a dostat zprávu hned
Systémy si mezi sebou mohou předávat informace dvěma základními způsoby. Buď se jeden systém pravidelně ptá druhého, jestli se něco změnilo (polling), nebo dostane zprávu přesně ve chvíli, kdy se něco stane (event-driven, přes službu jako Pub/Sub od Google Cloudu). Pub/Sub funguje jednoduše: jeden systém "publikuje" událost (např. "vznikla nová objednávka"), a libovolný počet "odběratelů" na ni reaguje okamžitě, bez čekání na další kolo dotazování.
Dotazování v intervalech
Systém se každých pár minut zeptá zdrojového systému: "změnilo se něco?" I když se nic nestalo, dotaz proběhne a zatíží zdroj. Pokud se něco stane hned po posledním dotazu, reakce přijde až při dalším kole, tedy s prodlevou danou intervalem.
Reakce na událost
Zdrojový systém pošle zprávu ve chvíli, kdy se něco reálně stane, ne podle pevného harmonogramu. Odběratel na ni reaguje prakticky ihned, bez ohledu na to, jak dlouhý je jinde nastavený interval dotazování.
Kde v e-shopu na tom reálně záleží
U většiny reportů rozdíl mezi minutami a hodinami zpoždění nehraje roli. U dvou situací ale ano: nová objednávka, kterou je potřeba hned poslat dál (do skladu, do fakturace, do potvrzovacího e-mailu), a výpadek skladu u zboží, kde každá minuta prodlevy znamená prodej zboží, které fyzicky není k dispozici.
Kde firmy pálí peníze
Chyba nejde jen jedním směrem. Stejně jako firmy zbytečně dotazují tam, kde by stačilo reagovat na událost, občas nasadí event-driven architekturu tam, kde na tom nezáleží.
Zbytečné dotazování zatěžuje zdroj i rozpočet
Pravidelné dotazování i tam, kde by stačilo reagovat na konkrétní událost, zbytečně zatěžuje zdrojový systém (API má limity, každý dotaz stojí čas i výkon) a reakce na skutečnou změnu přichází v řádu minut místo vteřin.
Honba za event-driven architekturou bez důvodu
Opačná chyba je nasadit streamované, na události reagující zpracování všude, i tam, kde na rychlosti reakce reálně nezáleží. Přidává to komplexitu a náklady bez odpovídajícího přínosu. Kdy real-time skutečně dává smysl a kdy je to zbytečný náklad navíc, rozebíráme v pojmu Real-time reporting, v části "Real-time za každou cenu".
Objednávka nebo výpadek skladu zpracované se zpožděním
Pokud se objednávka nebo změna skladové dostupnosti zpracovává jen v dávkách (např. jednou za hodinu), a situace přitom vyžaduje okamžitou reakci, firma o problému (nebo příležitosti) ví později, než by mohla, i když technicky měla data k dispozici.
Kdy dává smysl streamované zpracování zvážit
Streamované, na události reagující zpracování je architektonická volba pro konkrétní případ, ne standardní součást každého napojení. Datimo staví napojení na míru, typicky jako nezávislé komponenty v Docker kontejnerech na Cloud Run, a Pub/Sub je jedna z možností, jak takovou komponentu spustit ve chvíli, kdy nastane událost, místo podle pevného rozvrhu.
Vysoký objem objednávek
Pokud e-shop zpracovává objednávky v takovém objemu nebo tempu, že dávkové zpracování jednou za hodinu vytváří reálnou prodlevu v navazujících krocích (sklad, fakturace, notifikace), streamované zpracování tuto prodlevu odstraní.
Kritická reakce na výpadek skladu
Tam, kde prodej zboží, které už není na skladě, stojí reálné peníze nebo poškozuje vztah se zákazníkem, dává smysl reagovat na změnu dostupnosti okamžitě, ne až při dalším běhu dávky.
Není to univerzální výchozí nastavení
Pro většinu napojení, reportů a datových toků je dávkové zpracování v pravidelných intervalech dostatečné, jednodušší na provoz i levnější. Streamované zpracování přes Pub/Sub zvažujeme jen tam, kde konkrétní byznys situace okamžitou reakci vyžaduje.