Was sind Circuit Breaker, Retry und Fallback in der Praxis?
Direkte Antwort
Circuit Breaker verhindert wiederholte Aufrufe an einen erkennbar ausgefallenen Service, Retry mit Backoff wiederholt fehlgeschlagene Aufrufe kontrolliert statt sofort und unbegrenzt, und Fallback liefert eine reduzierte, aber funktionierende Antwort, wenn eine Abhängigkeit nicht verfügbar ist. Zusammen verhindern diese drei Muster, dass ein einzelner Teilausfall das gesamte System mitreißt.
"Ohne Resilience-Muster wird der Ausfall eines einzelnen, unwichtigen Services schnell zum Ausfall des gesamten Systems, weil jeder wartende Aufruf Ressourcen blockiert.
In verteilten Systemen ist der Ausfall einer einzelnen Abhängigkeit die Regel, nicht die Ausnahme — die Frage ist, ob dieser Ausfall lokal bleibt oder sich durch das ganze System fortpflanzt.
Circuit Breaker — schnelles Scheitern statt endlosem Warten
Ein Circuit Breaker überwacht die Fehlerrate eines Aufrufs an einen anderen Service und "öffnet" sich nach einer Schwellenwertüberschreitung, sodass weitere Aufrufe sofort fehlschlagen, statt auf einen absehbar erfolglosen Antwortversuch zu warten.
Das verhindert, dass Ressourcen (Threads, Verbindungen) durch das Warten auf einen bereits ausgefallenen Service blockiert werden, was sonst auch gesunde Teile des Systems in Mitleidenschaft ziehen kann.
Retry mit Backoff statt naivem Wiederholen
Ein einfacher, sofortiger Retry bei jedem Fehler kann einen bereits überlasteten Service zusätzlich belasten und den Ausfall verschlimmern. Retry mit exponentiellem Backoff und Jitter wartet zwischen Versuchen zunehmend länger und streut die Wiederholungszeitpunkte, um genau das zu vermeiden.
Retries sollten zudem nur bei tatsächlich transienten Fehlern erfolgen (Netzwerkzeitüberschreitung), nicht bei Fehlern, die garantiert erneut auftreten (etwa ein 400er-Statuscode wegen fehlerhafter Eingabe).
Fallback als letzte Verteidigungslinie
Ein Fallback liefert eine reduzierte, aber funktionsfähige Antwort, wenn eine Abhängigkeit nicht verfügbar ist — etwa zwischengespeicherte, leicht veraltete Daten statt eines kompletten Fehlers.
Dieses Muster erfordert eine bewusste fachliche Entscheidung, welche reduzierte Antwort akzeptabel ist, und lässt sich nicht rein technisch automatisieren — für manche Anfragen ist ein klarer Fehler ehrlicher als eine irreführend veraltete Antwort.
Wann passt es — wann nicht?
Passt gut
- ✓Das System hat mehrere externe oder interne Abhängigkeiten, deren Ausfall isoliert bleiben soll
Passt nicht
- ✗Es gibt nur eine einzige, stabile Abhängigkeit ohne bekannte Ausfallhistorie