Microservices & Cloud Native
Was sind Circuit Breaker, Retry und Fallback in der Praxis?
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.
Nextise Wissen · · 6 Minuten Lesezeit
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.
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, wenn …
- Das System hat mehrere externe oder interne Abhängigkeiten, deren Ausfall isoliert bleiben soll
Ein anderer Ansatz ist nötig, wenn …
- Es gibt nur eine einzige, stabile Abhängigkeit ohne bekannte Ausfallhistorie
Wissen allein reicht nicht — wir zeigen, wie es im Betrieb funktioniert.
Unsere Seminare verbinden die Konzepte aus dem Wissen-Hub mit konkreter Praxis. Ihr Team lernt direkt an eigenen Aufgaben — praxisnah, kompakt, sofort anwendbar.
Schulungen entdeckenLassen Sie uns über Ihr nächstes Training sprechen.
Unser Team steht Ihnen rund um die Uhr zur Verfügung und freut sich auf Ihre Anfrage. Einfach anrufen oder eine Nachricht hinterlassen – wir kümmern uns schnellstmöglich um Ihre Anfrage, ob es um eine Schulung, einen Vortrag oder eine Präsentation geht. Jetzt loslegen!
Selina Schmid
Leiterin Kodschul