Zaplaceno, neodesláno: když propojení tiše přestane fungovat.

Dvě stě čtrnáct objednávek, žádná chyba v logu.

Vývojář Sergey Shinder popsal případ ze své firmy. Při víkendové odsouhlasovací kontrole financí se ve středu ukázalo, že 214 objednávek bylo zaplaceno a nikdy neodesláno, a čtyři z těch zákazníků už stihli volat (dev.to, Sergey Shinder, 23. 9. 2026). Autor píše: "V žádném logu nebyla chyba, nespustil se žádný alarm a všechny přehledy z toho víkendu jsou zelené, protože z pohledu našich systémů nic neselhalo."

Příčina byla banální. Objednávkový systém objednávku uloží a pak pošle zprávu skladu. V sobotu ráno nebyl prostředník, který zprávy předává, dostupný 12 minut kvůli údržbě na jeho vlastním serveru (dev.to, Sergey Shinder, 23. 9. 2026). Odeslání zprávy selhalo. Kdosi před lety ten krok obalil tak, aby selhání jen zapsal do logu s nízkou závažností, protože objednávka je přece uložená a zákazníkovi nemá padnout nákup kvůli technické závadě na pozadí.

Systém si zapsal něco, co není pravda.

Autor to shrnuje tak, že dva zápisy do dvou systémů v jednom požadavku mají čtyři možné výsledky a oni počítali jen se dvěma. Stav, kdy první zápis projde a druhý ne, podle něj není chybový stav. Je to systém, který o sobě zapsal nepravdu a pokračuje dál s plnou jistotou.

Tohle není problém programátorů z jednoho e-shopu. Stejný tvar má každé propojení, které po úspěšném kroku jen doufá, že druhý krok dopadl. Platba prošla, ale doklad se v účetnictví nevytvořil. Objednávka je v e-shopu, ale ve skladu chybí. Nikdo nedostal chybovou hlášku, takže nikdo nic neopravuje.

Propojení potřebuje vlastníka a kontrolu počtů.

U českých firem vidím stejné místo: e-shop, sklad a účetnictví si předávají data a všichni předpokládají, že to prostě jede. Propojení má v takové firmě často autora, který odešel, a dodavatele, který o provozu ví jen to, co mu nahlásíte. Když si podobné propojení teprve vybíráte, přečtěte si, co se dá propojit samo a co to od firmy vyžaduje.

Funguje jednoduché pravidlo: někdo konkrétní odpovídá za to, že počty na obou stranách sedí. Každý den porovná, kolik zaplacených objednávek je v e-shopu a kolik jich dorazilo do skladu a do účetnictví. Rozdíl je signál, ještě než zavolá první zákazník. Bez jmenovaného člověka se kontrola dělá jen po průšvihu.

Co zavedl autor a co z toho převzít.

Autor událost o objednávce zapisuje do tabulky přímo v databázi, ve stejné chvíli jako samotnou objednávku, takže se uloží obojí, nebo nic. Samostatná část systému tuto tabulku čte, zprávy odesílá, označuje je jako odeslané a opakuje, dokud to nejde (dev.to, Sergey Shinder, 23. 9. 2026). Nejužitější věc, která z toho vyšla, je podle něj alarm na stáří nejstarší neodeslané zprávy. Limit jsou 2 minuty a alarm se od té doby spustil třikrát, pokaždé kvůli něčemu, co by firma jinak zjistila až ve středu.

Technické řešení patří vývojáři. Zásadu si ale může převzít každý majitel firmy a ptát se jí dodavatele:

• Co se stane, když druhý krok propojení selže: zapíše se to, zkusí se to znovu, nebo se to ztratí?
• Kdo se dozví, že nějaký záznam zůstal viset, a jak rychle?
• Existuje přehled záznamů, které jsou na jedné straně a na druhé chybí?
• Kdo ve firmě tuto zprávu čte a co s ní udělá?

Autor to uzavírá větou, kterou stojí za to přenést i mimo programování: "Systém, který umí zaznamenat jen své úspěchy, ztratí přesně tu práci, která selhala uprostřed."

Co s tím teď.

Pokud máte záznamy jen v jednom systému a nic se nikam nepředává, tento problém nemáte a nic řešit nemusíte. Pokud se data předávají samy a nikdo nehlídá, že dorazila, je to otázka času, kdy se to ukáže. Podrobněji popisuji, jak propojení systémů dělám.