Was ist ein Circuit Breaker? Kaskadierende Ausfälle (Cascading Failures) verhindern

In verteilten Systemen und Microservice-Architekturen ist das gefährlichste Szenario nicht der vollständige Absturz eines Dienstes, sondern seine Verlangsamung. Ein abgestürzter Dienst gibt sofort Connection Refused zurück und gibt Ressourcen frei – ein langsamer Dienst hingegen blockiert schleichend alle aufrufenden Systeme.

Die Falle langsamer Dienste & Cascading Failure

Stellen Sie sich vor, ein Zahlungs- oder Versanddienst antwortet statt in 150ms plötzlich erst nach 15 Sekunden:

1. Thread Pool Exhaustion: Das API-Gateway reserviert für jede eingehende Anfrage einen Worker-Thread und wartet auf die langsame Antwort.
2. Ressourcenerschöpfung: Während pro Sekunde hunderte neue Anfragen eintreffen, bleibt kein Thread frei. Innerhalb weniger Sekunden sind Arbeitsspeicher, Sockets und Thread-Pools komplett ausgeschöpft.
3. Dominoeffekt (Cascading Failure): Selbst völlig unabhängige Endpunkte wie „Profil bearbeiten“ oder „Produktsuche“ können nicht mehr antworten. Ein einziger langsamer Dienst reißt die gesamte Plattform mit in den Abgrund.

Die Lösung: Das Circuit-Breaker-Muster

Genau wie eine Sicherung im Stromkasten bei Überlastung herausspringt, um einen Kabelbrand zu verhindern, überwacht der Circuit Breaker ausgehende Aufrufe in Echtzeit über drei Zustände:

1. Closed (Geschlossen — Normalbetrieb)

Der Datenverkehr fließt normal zum Zieldienst. Im Hintergrund misst der Circuit Breaker die Fehler- und Timeout-Rate. Solange diese unter dem Schwellenwert (z. B. 50 %) bleibt, bleibt der Stromkreis geschlossen.

2. Open (Offen — Fail-Fast & Fallback)

Überschreitet die Fehlerrate den Schwellenwert, springt die Sicherung heraus (Open).

• Anfragen werden nicht mehr an den überlasteten Dienst weitergeleitet.
• Statt 15 Sekunden zu warten, antwortet das System sofort in 1ms (Fail-Fast) oder liefert eine Fallback-Antwort (z. B. aus dem Redis-Cache).
• Dadurch bleiben die Ressourcen des Hauptsystems geschützt und der ausgefallene Dienst erhält Zeit zur Erholung.

3. Half-Open (Halboffen — Kontrollierter Erholungstest)

Nach einer definierten Wartezeit (resetTimeout, z. B. 30 Sekunden) wechselt der Zustand auf Half-Open.

• Nur einzelne Testanfragen werden durchgelassen.
• Sind diese erfolgreich, schließt sich der Kreis wieder (Closed – Self-Healing). Schlagen sie fehl, springt der Schalter sofort wieder auf Open.

In Produktionsumgebungen setzen Teams hierfür auf bewährte Bibliotheken wie Resilience4j (Java), Polly (.NET), Opossum (Node.js) oder Service-Meshes wie Envoy / Istio.