Timeouts, Wiederholungen und Backoff mit Jitter

Ziel

Einen Client widerstandsfähig gegen vorübergehende Fehler machen, ohne einen Ausfall zu verstärken oder Arbeit zu duplizieren.

Voraussetzungen

Kenntnis darüber, welche Operationen idempotent sind (oder durch Idempotenzschlüssel geschützt), und was der Server bei Überlastung signalisiert (429 oder 503 mit Retry-After).

Schritte

1. Für jeden entfernten Aufruf ein Connect-Timeout und ein Read-Timeout setzen; beide aus der eigenen Frist des Aufrufers ableiten, nicht aus dem langsamsten beobachteten Fall.
2. Nur bei vorübergehenden Ausgängen wiederholen: Verbindungsfehler, Timeouts, 429, 503, 502/504 von Zwischenstationen. Bei 4xx-Validierungsfehlern nie wiederholen.
3. Nur idempotente Operationen wiederholen oder solche mit einem Idempotenzschlüssel; ein einfaches POST wird nur wiederholt, wenn der Server idempotentes Verhalten dokumentiert.
4. Wiederholungsversuche exponentiell staffeln (Basis × 2^Versuch) mit zufälligem Jitter, wie es die zitierte AWS-Analyse empfiehlt, und sowohl die Verzögerung als auch die Anzahl der Versuche begrenzen.
5. Retry-After befolgen, wenn der Server es sendet; es überschreibt die berechnete Verzögerung.
6. Einen Circuit Breaker oder ein Budget einbauen, damit eine ausfallende Abhängigkeit nicht die gesamte Client-Kapazität verbraucht.

Erwartetes Ergebnis

Clients erholen sich automatisch von kurzen Ausfällen, die Last auf einem sich erholenden Server steigt gleichmässig an, und keine Operation wird versehentlich zweimal ausgeführt.

Grenzen und Prüfbasis

Wiederholungsversuche erhöhen die Latenz; interaktive Pfade bevorzugen unter Umständen ein schnelles Scheitern. Die Backoff-Parameter müssen pro Abhängigkeit abgestimmt werden. Die Empfehlungen folgen den zitierten Quellen und der Praxis des Beispiel-Clients dieses Wikis.

Informative Rate-Limit-Header

Manche Server kündigen ihre Limits an, bevor überhaupt ein 429 auftritt. Ein IETF-Entwurf (draft-ietf-httpapi-ratelimit-headers) definiert ein Feld RateLimit, das das verbleibende Kontingent und die Sekunden bis zum Zurücksetzen trägt, sowie ein Feld RateLimit-Policy, das die Richtlinie beschreibt; andere Server senden herstellerspezifische Header mit derselben Bedeutung. Sind solche Felder vorhanden, sollten sie gelesen werden, um die Rate zu drosseln, bevor das Kontingent null erreicht, nicht erst danach; sie sind als Hinweise zu behandeln, die fehlen oder sich in der Form ändern können, wobei der Backoff aus den Schritten 4 und 5 als Rückfallebene bestehen bleibt. Ein informativer Header darf die Anfragerate nie über das hinaus anheben, was das eigene Budget des Aufrufers erlaubt.