Zum Hauptinhalt springen

Circuit Breaker

Einleitung​

Der Circuit Breaker schützt Systeme vor Kaskaden-Fehlern und Ressourcenerschöpfung, indem er fehlschlagende Abhängigkeiten temporär „abschaltet“.

Statt weiterhin erfolglose Requests zu senden, wird die Verbindung unterbrochen und optional ein Fallback ausgelöst.

Ziel:

Fehler isolieren, bevor sie das gesamte System destabilisieren.

Einordnung

Circuit Breaker ist ein Micro-Pattern für Resilienz.

Typische Einsatzfelder:

  • Microservices
  • SOA
  • Cloud-native Systeme
  • Service Mesh / HTTP-Clients

Er wirkt auf Remote-Kommunikationsebene, nicht auf fachlicher Ebene.

Grundprinzip

Zustände

1️⃣ Closed​

  • Requests werden normal durchgeleitet
  • Fehler werden gezählt

2️⃣ Open​

  • Requests werden nicht mehr weitergeleitet
  • Sofortiger Fallback oder Fehler
  • Schutz vor Überlastung

3️⃣ Half-Open​

  • Einzelne Test-Requests werden zugelassen
  • Bei Erfolg → Closed
  • Bei Fehler → zurück zu Open

Zusammenspiel mit anderen Patterns

Timeout​

Ohne Timeouts kein Circuit Breaker.

Timeout definiert:

  • wann ein Request als fehlgeschlagen gilt

Retry​

Retry + Circuit Breaker müssen abgestimmt sein:

  • Zu aggressive Retries können Breaker triggern
  • Retry sollte mit Backoff arbeiten

Bulkhead​

Bulkhead isoliert Ressourcen (Threads/Connections). Circuit Breaker verhindert unnötige Last.

Beide ergänzen sich.

Vorteile

  • Verhindert Kaskaden-Ausfälle
  • Schützt Ressourcen (Threads, Connection Pools)
  • Stabilisiert Gesamtsystem unter Teilausfall
  • Ermöglicht Graceful Degradation

Risiken / typische Fallstricke

1️⃣ Falsches Tuning​

  • Schwellenwerte zu niedrig → Dauer-Open
  • Schwellenwerte zu hoch → Schutz greift zu spät

2️⃣ Fallback verfälscht Business-Logik​

Beispiele:

  • „Bestellung angenommen“, obwohl Payment-Service down
  • „Bestand vorhanden“, obwohl Inventar nicht erreichbar

Fallbacks müssen fachlich verantwortet werden.

3️⃣ Verwechslung mit Fehlerbehandlung​

Circuit Breaker:

  • ersetzt keine fachliche Kompensation
  • löst keine Konsistenzprobleme

Er ist ein Stabilitätsmechanismus.

Monitoring-Anforderungen

Wichtige Metriken:

  • Error-Rate
  • Timeout-Rate
  • Open-State-Dauer
  • Anzahl Half-Open-Transitions

Ohne Monitoring ist Tuning unmöglich.

Wann sinnvoll?

  • Remote-Calls über Netzwerk
  • Abhängigkeiten mit instabiler Latenz
  • Hohe Last oder viele Service-Ketten
  • Externe APIs mit unklarer Verfügbarkeit

Wann unnötig?

  • Lokale In-Process-Aufrufe
  • Sehr einfache, nicht kritische Systeme
  • Single-Service-Monolith ohne Remote-Abhängigkeit

Strategische Perspektive

Circuit Breaker ist kein Business-Pattern.

Er ist:

  • ein Schutzmechanismus
  • ein Stabilitätsinstrument
  • eine Voraussetzung für robuste Microservices

Ohne ihn entstehen bei Teilausfällen:

Thread-Pool-Erschöpfung Timeout-Ketten Systemweite Instabilität

Fazit

Circuit Breaker:

  • isoliert Fehler
  • schützt Ressourcen
  • ermöglicht kontrollierte Degradation

Er ersetzt keine saubere Architektur – aber er verhindert, dass kleine Fehler große Systeme zum Einsturz bringen.