Circuit Breaker und Degradation

Circuit Breaker (CB) ist ein Schutzmuster, das Anrufe zu einer degradierten Abhängigkeit unterbricht, um den Ausfall zu lokalisieren und Upstream-Dienste und Benutzer zu schützen. Degradation (graceful degradation) - bewusste Vereinfachung der Funktionalität bei Ressourcenmangel oder Ausfällen (z. B. Rückgabe von zwischengespeicherten/unvollständigen Daten, Deaktivieren von „teuren“ Daten) ohne vollständiges Downtime.

Oberstes Ziel: SLO und User Experience durch kontrollierte Ausfälle zu erhalten, statt kaskadierende Stürze.

1) Wann anzuwenden

Die Abhängigkeit ist instabil: p95/p99-Wachstum, Timeouts, fehlerhafte Antworten.
Externe APIs mit engen Grenzen/Penalty.
„Schwere“ Backends (Suche, Empfehlungen, Berichte), bei denen Retrays den Sturm verstärken.
Stark belastete Gebiete mit dem Risiko der Erschöpfung von Pools (Verbindungen, Threads).

2) CB-Zustände und Übergänge

1. Geschlossen - Der Datenverkehr läuft, Fehler-/Latenzmetriken werden gezählt.

2. Öffnen - Anrufe werden sofort abgelehnt (fail-fast) und/oder auf fallback übertragen.

3. Half-Open - Eine begrenzte Anzahl von „Test“ -Anfragen bestimmt, ob der Schalter geschlossen wird.

Auslöser der Öffnung

Fehler-/Timeout-Schwelle pro Fenster (z. B. ≥ 50% der letzten N).
Latenzschwelle (z.B. p95> Zielwert).
Kombinierte Richtlinien (Fehler ∧ Überschreitung der Zeitüberschreitung).

Haltezeit (Cool-Down)

Fest (z.B. 10-60 sec) oder adaptiv (exponentieller Anstieg bei wiederholter Auslösung).

3) Timeouts, Retrays und Jitter

Die Timeouts sind immer kürzer als der SLO-Upstream und in der Kette aufeinander abgestimmt (Deadline Propagation).
Retrai nur für idempotente Operationen; 1-2 Versuche sind in den meisten Fällen ausreichend.
Backoff + Jitter (Full Jitter) verhindert synchrone Wiederholungswellen.
Hedging (Ersatzanfragen) - wirtschaftlich und nur für sehr kritische Lesungen.

4) Bulkhead-Isolierung und „Sicherungen“

Trennen Sie Verbindungspools/Worker/Warteschlangen nach Domänen und Verkehrstypen (VIP, Hintergrundaufgaben, öffentliche APIs).
Caps auf concurrency für „teure“ Operationen.
Admission Control: Einfache Fehler vor der Ausführung, wenn die Warteschlange überläuft.

5) Fallback und Degradationsszenarien

Varianten

Cache/Steal-Antworten: 'stale-while-revalidate', Rückmeldung von Daten aus dem L2/L3 Cache.
Read-only: Block schreiben/Befehle, erlauben sichere Lesungen.
Surrogatantworten: unvollständige Daten (z.B. keine Empfehlungen/Avatare).
Funktionale Abschaltung: Nicht-kritische Widgets/Features vorübergehend ausblenden.
Feature flags: schnelle Verhaltensänderung ohne Freigabe.

Regeln

Fallback muss deterministisch, schnell und datensicher sein.
Markieren Sie den degradierten Pfad explizit in Protokollen/Traces/Metriken.

6) Priorisierung und Traffic-Shaping

VIP/bezahlte Pläne - höhere Priorität/Quoten bei Knappheit.
Rate Limits und Throttling reduzieren die Belastung degradierter Abhängigkeiten.
Shed load: sanfte Qualitätsminderung (z.B. weniger Ergebnisse, abgespeckte Bilder) bis zur Stabilisierung.

7) Beobachtbarkeit und Signalisierung

CB-Metriken

Status (closed/open/half-open) und Dauer im Status.
Fehleranteil aus Gründen: CB-open, timeout, 5xx, retry-exhausted.
p95/p99 Latenz „vor“ und „nach“ des Schalters.
Anzahl/Anteil der Anfragen über fallback.

Tracing

Anmerkungen der Spans: 'circuit = opened', 'fallback = cache', 'admission = denied'.
Korrelation mit Limits (429/RateLimit-), Warteschlangen und Verbindungsbällen.

Protokolle/Audit

Grund für das Öffnen/Schließen, Schwellenwerte, Abhängigkeitskennungen.

8) Verträge und Protokoll

HTTP

Fail-fast: '503 Service Unavailable' mit 'Retry-After' (oder '429' bei Limits).
Partieller Inhalt/Steal: '200 '/' 206' mit Abbaumetadaten (z.B. 'X-Degraded: true').
Cache-Richtlinien: „Cache-Control: stale-if-error, stale-while-revalidate“.

gRPC

'UNAVAILABLE', 'DEADLINE _ EXCEEDED', die Semantik der Retrays nach Client/Proxy-Policen.
Deadline/Timeout auf Anforderungskontext; Die Deadline wird in der Kette nach unten verteilt.

Idempotenz

„Idempotency-Key“ für POST-Operationen, Deduplizierung an der Grenze.

9) Typische Implementierung (Pseudocode)

pseudo onRequest(req):
if circuit. isOpen(dep):
return fallbackOrFail(req)

with timeout(T):
try:
resp = call(dep, req)
circuit. recordSuccess(dep, latency=resp. latency)
return resp except TimeoutError or 5xx as e:
circuit. recordFailure(dep)
if circuit. shouldOpen(dep):
circuit. open(dep, coolDown=adaptive())
return fallbackOrFail(req)

Half-Open-Test

pseudo onTimer():
if circuit. state(dep) == OPEN and coolDownExpired():
circuit. toHalfOpen(dep)

onRequestHalfOpen(req):
if circuit. allowTrial (dep): # e.g. 1 try: call -> success => close catch: reopen with longer coolDown else:
return fallbackOrFail(req)

10) Schwellenwerte einstellen

Beobachtungsfenster: gleitende N Sekunden/Abfragen.
Fehlerschwelle: 20-50% im Fenster (profilabhängig).
Latenzschwelle: p95 ≤ Ziel-SLO (z. B. 300-500 ms); Überschreitung wird als „Fehler“ für CB berücksichtigt.
Adaptives Cool-Down: 10s → 30s → 60s bei wiederholter Betätigung.

11) Test- und Chaos-Praktiken

Chaos: Latenz-/Fehlerinjektion in Abhängigkeit, DNS-Panne, Drop-Pakete.
Spieltage: Start der „Öffnung“ des Schalters auf einer bojenartigen Umgebung, Überprüfung des Fallbacks.
Canary: Schließen Sie CB/degradation policies zuerst für 1-5% Verkehr ein.
SLO-Budget: Experimente zulassen, bis das Error-Budget erschöpft ist.

12) Integration mit mehreren Tenanten

Der CB-Zustand kann per dependency per tenant (für laute Mieter) oder global gespeichert werden - je nach Lastprofil.
Fallback-Daten und Caches nach 'tenant _ id' segmentieren.
Prioritäten/Quoten - nach den Plänen (VIP soll nicht unter dem Starter-Verhalten leiden).

13) Checkliste vor dem Verkauf

• Timeouts und Deadlines sind durchgängig und konsistent.
• Retrays sind begrenzt, nur für idempotente Operationen, mit Backoff + Jitter.
• Die CB-Schwellenwerte sind durch Lastprüfdaten gerechtfertigt.
• Fallback-Pfade existieren, schnell und sicher; Der Richtliniencache ist definiert.
• Bulkhead-Isolation: getrennte Pools/Warteschlangen/Limits.
• Metriken/Traces/Logs markieren Degradationen und CB-Zustände.
• Dokumentation der Antwortverträge (HTTP/gRPC) mit Beispielen für Header/Codes.
• Chaos-Szenarien und Game-Days finden regelmäßig statt; Es gibt ein Runbook.

14) Typische Fehler

Es gibt keine Timeouts → Retrays „bis zum Anschlag“ und kaskadierende Stürze.
Eine einzige globale CB anstelle einer selektiven (nach Endpoint/Methode) - unnötige Ausfälle.
Offener Schalter ohne Fallback → „leere“ Bildschirme statt degradierter UX.
Retrays ohne Jitter → synchrone Anfragestürme.
Langes Cool-Down bei kurzfristigen Ausfällen oder zu kurz bei stabilen - „Flip-Flop“ -Zuständen.
Mangel an Bulkhead - Erschöpfung gemeinsamer Pools und „Head-of-Line-Blocking“.

15) Schnelle Strategieauswahl

Lesungen von hoher Bedeutung: CB + Steal Response Cache + Hedging (wirtschaftlich).
Aufzeichnungen/Zahlungen: strenge Timeouts, minimale Retraits, idempotency Keys, kein „schmutziges“ Fallback.
Externe APIs: CB mit aggressiven Schwellenwerten, adaptives Cool-Down, strenges Throttling.
Microservices mit pulsierender Last: Bulkheads, Caps auf Concurrency, VIP-Priorisierung.

Schlussfolgerung

Circuit Breaker und Managed Degradation sind die „Versicherung“ der Architektur: Sie übersetzen chaotische Ausfälle in vorhersehbares Verhalten. Klare Timeouts, limitierte Jitter-Retrays, vereinzelte Pools, durchdachte Fallback-Pfade und Telemetrie machen das System widerstandsfähig gegen Abhängigkeitsausfälle und halten SLOs auch in Stoß- und Notzeiten.