Wie funktionieren Circuit Breaker und Wiederholungen mit Exponential Backoff in verteilten Systemen?

Question

Accepted Answer

In verteilten Systemen schlagen Aufrufe fehl. **Wiederholungen mit Exponential Backoff** erholen sich von *vorübergehenden* Fehlern; ein **Circuit Breaker** verhindert, dass du eine abhängigkeit belagst, die wirklich *ausfällt*. Sie ergänzen sich: versuche erneut bei kurzfristigen Fehlern, unterbreche bei Ausfällen.

## Wiederholung mit exponentiellem Backoff + Jitter

Bei vorübergehenden Ausfällen (Timeouts, kurzzeitige Netzwerkausfälle, 503er), versuche erneut — aber **exponentiell zurückfahren und Jitter hinzufügen**, damit Wiederholungen verteilt werden statt synchronisiert zu einer Überschwemmung.

```text
attempt 1 → wait ~1s   (+ random jitter)
attempt 2 → wait ~2s   (+ random jitter)
attempt 3 → wait ~4s   (+ random jitter)
→ cap at maxRetries (e.g. 3) and a max delay → don't retry forever
```

Wichtigste Vorsichtsmaßnahmen:

- **Wiederholungen begrenzen** — unbegrenzte Wiederholungen erzeugen **Wiederholungsstürme**, die einen sich erholenden Service überlasten.
- **Idempotenz** — versuchen Sie nur Operationen, die sicher zu wiederholen sind (eine wiederholte Zahlung darf nicht zweimal berechnet werden).
- **Jitter** — ohne sie versuchen alle Clients im gleichen Moment erneut und verursachen einen erneuten Anstieg der Last.

## Warum es wichtig ist

Ohne diese würde ein fehlschlagender Abhängiger den Aufrufer mit sich reißen: Anfragen stauen sich bei Timeouts, Wiederholungen verstärken die Last, und der Fehler kaskadiertüber Services. Exponentieller Backoff mit Jitter erholt sich von Störungen ohne einen Wiederholungssturm; Begrenzung und Idempotenz halten Wiederholungen sicher; und der Circuit Breaker stoppt die Ressourcenverschwendung auf einer toten Abhängigkeit und gibt ihr Platz zum Erholen. Zusammen verwandeln sie einen Abhängigkeitsfehler in ein eingegrenztes, selbstheilendes Ereignis.

## Circuit Breaker

Ein Circuit Breaker verfolgt Ausfälle einer abhängigkeit und **öffnet** nach einem Schwellwert — schlägt schnell fehl (oder gibt einen Fallback zurück) statt einen toten Service aufzurufen. Nach einer Abkühlphase wird er **halb-offen**, um die Wiederherstellung zu überprüfen.

```text
CLOSED   → calls pass through; count failures
  too many failures → trip → OPEN
OPEN     → fail fast immediately (no call); start cooldown timer
  cooldown elapsed → HALF-OPEN
HALF-OPEN → allow a few probe calls
  success → CLOSED (recovered) ; failure → back to OPEN
```

## Wann jedes angewendet wird

```text
Retry           → transient, likely-to-succeed-soon errors (1 slow call)
Circuit breaker → repeated/sustained failures (the dependency is down)
→ use together: breaker prevents retries from piling onto a dead service
```