Ponowienia: kiedy ratują, a kiedy pogarszają sprawę

Ponawianie nieudanej operacji to najpowszechniejszy wzorzec niezawodności i jeden z najłatwiejszych do katastrofalnego zepsucia. Zrobione dobrze, przejściowe awarie znikają, zanim ktokolwiek je zauważy. Zrobione źle, Twoi własni klienci dobijają usługę, która już i tak ledwo żyje.

Ponawiaj tylko to, co można ponowić

Timeout warto ponowić; błąd 400 nie, i nigdy nie będzie warto. Ponawianie deterministycznej awarii to tylko wolniejszy sposób na porażkę, który dodatkowo generuje obciążenie. Pierwsza decyzja zawsze dotyczy tego, czy dana klasa błędów może się udać przy drugiej próbie.

Zasady, które mają znaczenie

• Wykładniczy backoff z jitterem — zsynchronizowane ponowienia to samodzielnie wywołane stado bizonów.
• Sztywny limit prób i zdefiniowane miejsce docelowe dla tego, co je wyczerpało.
• Idempotentność, bo inaczej Twoje ponowienie obciąży klienta dwukrotnie.
• Circuit breaker, żeby przestać walić w coś, co wyraźnie leży.

To decyzje polityki, a nie szczegóły kodu — dlatego powinny być w widocznym miejscu. Gałąź ponowienia z napisem „+72 h, maks. 3” można audytować; stała zakopana w usłudze — nie.