Stanovte časový rozpočet celého procesu, nastavte timeout pro spojení i odpověď, opakujte pouze bezpečné dočasné chyby s exponenciálním odstupem a rozptylem, respektujte limit poskytovatele a idempotenci a po vyčerpání pokusů přesuňte úlohu do viditelného opravného stavu.
API integrace musí počítat s pomalou odpovědí, dočasnou nedostupností i limitem počtu volání. Bez timeoutu může jedno spojení blokovat pracovní procesy a zdroje. Bez řízeného opakování se dočasná chyba změní ve ztracená data. Příliš agresivní retry však zatíží oslabenou službu a vytvoří lavinu, která výpadek prodlouží.
Odolnost vzniká kombinací rozumného časového rozpočtu, rozlišení chyb, idempotence, rostoucího odstupu, náhodného rozptylu a fronty. Hodnoty nelze univerzálně zkopírovat. Musí vycházet z uživatelského procesu, kontraktu poskytovatele, objemu a důsledků zpoždění. Každý mechanismus potřebuje monitoring a hranici, po jejímž překročení zasáhne člověk.
Odvoďte timeout od celého uživatelského procesu
Nejprve určete, jak dlouho může čekat uživatel nebo navazující systém. Tento časový rozpočet rozdělte mezi DNS, spojení, přenos, zpracování a případné opakované pokusy. Timeout klienta nemá být delší než doba, po které nadřazená služba požadavek stejně zruší. Jinak pokračuje zbytečná práce bez příjemce výsledku.
Rozlišujte čas na navázání spojení a čas čtení odpovědi. Dlouhý export může legitimně trvat déle než jednoduché ověření. Pokud operace překračuje interaktivní časový rozpočet, změňte ji na asynchronní úlohu se stavem. Nezvyšujte timeout bez diagnózy; může jen zakrýt přetížení nebo zablokovaný proces.
Klasifikujte chyby před opakováním
Dočasná síťová chyba, přetížení nebo některé serverové odpovědi mohou být vhodné k opakování. Neplatný vstup, chybějící oprávnění nebo neexistující zdroj se dalším pokusem obvykle nezmění. Konkrétní pravidla určujte podle kontraktu API a těla chyby, nikoli jen podle široké skupiny stavových kódů.
U zápisu ověřte idempotenci ještě před zapnutím retry. Timeout neznamená, že server operaci neprovedl. Opakovaná platba nebo objednávka může mít větší dopad než původní výpadek. Pokud API neposkytuje bezpečný mechanismus, použijte ověření stavu nebo ruční kontrolu místo slepého opakování.
- dočasná chyba s reálnou šancí na zotavení
- idempotentní nebo bezpečně ověřitelná operace
- omezený počet pokusů a celkové stáří
- viditelný výsledek po definitivním selhání
Použijte odstup, rozptyl a respektujte rate limit
Mezi pokusy zvětšujte odstup a přidejte náhodný rozptyl, aby všichni klienti nezopakovali volání ve stejném okamžiku. Nastavte horní hranici času i počtu pokusů. Pokud poskytovatel vrátí informaci o dalším povoleném čase nebo zbývající kapacitě, zpracujte ji podle dokumentace a sdílejte rozpočet mezi workery.
Rate limit sledujte na úrovni účtu, endpointu nebo uživatele podle modelu služby. Paralelní workery potřebují koordinaci, jinak každý z nich věří, že má plnou kapacitu. Kritické operace upřednostněte před dávkovým importem. Cache nebo hromadný endpoint mohou snížit počet volání, pokud zachovají správnost a aktuálnost dat.
Oddělte uživatelský požadavek od fronty
Pokud externí API není potřeba pro okamžitou odpověď, uložte záměr a zpracujte jej ve frontě. Uživatel dostane potvrzení přijetí, nikoli falešný příslib dokončení. Fronta umožní omezit souběh, opakovat dočasné chyby a zachovat úlohu během výpadku. Každá zpráva potřebuje stabilní identitu a maximální stáří.
Po vyčerpání pokusů přesuňte úlohu do karantény s uvedením důvodu a bezpečného způsobu opravy. Nekonečné opakování spotřebovává kapacitu a zakrývá trvalou chybu v datech. Při delším výpadku může ochranný mechanismus dočasně zastavit volání a pravidelně ověřovat zotavení. Nesmí však zůstat vypnutý bez alarmu.
Monitorujte technický i obchodní výsledek
Sledujte latenci, timeouty, počet pokusů, odpovědi o překročení limitu, stáří fronty a podíl úloh v karanténě. Rozdělte metriky podle poskytovatele a operace. Průměrná doba může skrýt dlouhý chvost, který ovlivňuje zákazníky. Upozornění potřebuje vlastníka, práh a postup, nejen surovou chybu.
Technická úspěšnost neznamená kompletní proces. Porovnávejte počet přijatých objednávek, exportů nebo dokumentů s očekávaným tokem. Po změně limitu či klienta proveďte zátěžový a regresní test v povoleném prostředí. Kapacitní plán aktualizujte při růstu objemu, ne až po prvním hromadném selhání.
- stáří nejstarší čekající operace
- počet pokusů podle typu chyby
- využití limitu podle klienta a endpointu
- obchodní objekty chybějící v cílovém systému
- doba zotavení po uvolnění externí kapacity
- vliv dávkových úloh na kritická volání
Časté dotazy
Kolikrát se má požadavek API zopakovat?
Univerzální číslo neexistuje. Závisí na časovém rozpočtu, typu chyby, idempotenci, limitech a obchodním dopadu. Po dosažení hranice musí vzniknout viditelný opravný stav, nikoli tiché zahození.
Je delší timeout bezpečnější?
Ne automaticky. Dlouhý timeout váže prostředky a může překročit čas nadřazeného procesu. Nejprve diagnostikujte latenci a u dlouhé práce použijte asynchronní model se stavem.
Co dělat při překročení rate limitu?
Respektujte pokyny poskytovatele, zastavte agresivní opakování, rozložte požadavky a zkontrolujte souběh. Dlouhodobě omezte zbytečná volání, použijte dávky nebo domluvte vhodnou kapacitu.
Zdroje a další čtení
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
