Wykładnicze opóźnienie ponawiania (exponential backoff)

Wykładnicze opóźnienie ponawiania, po angielsku exponential backoff, to strategia dla procesu, który nie dostał poprawnej odpowiedzi z API albo zewnętrznej usługi. Zamiast wysyłać kolejne żądania natychmiast, proces robi przerwę rosnącą po każdej porażce. Przykładowy rytm to 1, 2, 4 i 8 sekund, zawsze z ustalonym limitem maksymalnego czekania oraz liczby prób. Chodzi nie o ukrycie błędu, ale o rozsądne potraktowanie błędu przejściowego: chwilowego przeciążenia, timeoutu albo krótkiej przerwy w sieci.

To ważne w systemie AI, który łączy formularz, CRM, model językowy i narzędzia takie jak n8n. Gdy dostawca modelu zwróci 429, czyli limit żądań, natychmiastowe ponowienie zwykle pogarsza sytuację. Gdy kilkadziesiąt procesów robi to w tym samym momencie, tworzą drugi pik ruchu. Rosnące opóźnienie zmniejsza presję na usługę i zwiększa szansę, że kolejna próba trafi po jej odzyskaniu. Google Cloud zaleca wykładniczy backoff z jitterem dla żądań spełniających warunki ponowienia i idempotencji.

Jitter to niewielka losowość dodana do czasu oczekiwania. Bez niej wiele zadań może wrócić dokładnie po 2, potem 4 sekundach i ponownie przeciążyć tę samą usługę. Z jitterem ich powroty rozchodzą się w czasie. AWS pokazuje, że samo wykładnicze wydłużanie przerw nadal tworzy skupiska prób, a rozproszenie czasu ogranicza liczbę wywołań przy dużej konkurencji. W gotowym konektorze najpierw sprawdź, czy ma własny mechanizm retry, zanim dodasz kolejny.

Nie każdy błąd wolno ponawiać. Błąd 400 oznaczający niepoprawne dane, brak wymaganego pola lub odrzucony format promptu nie naprawi się po minucie. Podobnie nie należy automatycznie powtarzać operacji, która mogła wykonać się po stronie usługi, ale odpowiedź zaginęła. Ponowienie tworzenia płatności, wysłania maila albo dodania leada może wtedy zrobić duplikat. Dlatego retry wymaga klasyfikacji błędów, limitu prób i bezpiecznej operacji idempotentnej albo klucza idempotencji.

Praktyczny przykład: webhook po zapisie na konsultację ma utworzyć kontakt w CRM i wygenerować spersonalizowaną notatkę przez API modelu. Dla odpowiedzi 429 lub krótkiego timeoutu ustaw maksymalnie cztery próby, np. opóźnienie bazowe 2 sekundy, mnożnik 2, limit 30 sekund oraz jitter. Przechowaj identyfikator zapisu jako klucz idempotencji. Po ostatniej nieudanej próbie wyślij zadanie do kolejki błędów i powiadom właściciela procesu. Nie uruchamiaj od początku całego workflow bez informacji, który krok już się udał.

Najczęstszy błąd to nakładanie retry w kilku warstwach. Jeśli n8n ponawia krok trzy razy, a używany SDK ponawia każde wywołanie trzy razy, pojedynczy problem może dać dziewięć prób. To wydłuża proces, zwiększa koszty modeli i utrudnia diagnozę. Ustal jedno miejsce odpowiedzialne za politykę ponowień. Loguj kod błędu, numer próby, docelową usługę oraz identyfikator zadania. Pierwsze nieudane próby mogą być informacją operacyjną, ale końcowe niepowodzenie musi być widoczne.

Wykładnicze opóźnienie jest narzędziem na awarie krótkotrwałe, nie lekarstwem na zły projekt. Jeśli ten sam endpoint regularnie zwraca limity albo timeouty, trzeba zmniejszyć ruch, rozdzielić zadania w czasie, poprawić kolejkę lub wybrać inny plan usługi. Przy dłuższej awarii warto połączyć retry z wzorcem circuit breaker, który chwilowo przestaje kierować ruch do niedostępnej usługi. Dzięki temu system nie mieli bez końca i nie ukrywa realnego problemu.