Erklär das Circuit-Breaker-Pattern und sag mir, wann es mehr schadet als nützt.

Ein Circuit Breaker zählt Fehler gegen eine Dependency, öffnet ab einem Schwellwert, sodass Aufrufe sofort scheitern statt sich zu stauen, und geht dann halb offen, um die Erholung mit einem Rinnsal Traffic zu testen. Er schützt Thread- und Connection-Pools vor Erschöpfung und stoppt kaskadierende Fehler. Er schadet, wenn die Schwellwerte zu eng sind, wenn der Fallback schlimmer ist als der Fehler, oder wenn alle Instanzen gleichzeitig öffnen und die Dependency nie genug Traffic bekommt, um ihre Erholung zu beweisen.

Geschlossen, offen, halb offen. Du zählst Fehler über ein rollierendes Fenster, und sobald du den Schwellwert überschreitest, öffnest du den Kreis und scheiterst für eine Abkühlphase sofort, danach lässt du ein paar Probe-Requests durch, um zu sehen, ob die Dependency wieder gesund ist. Der eigentliche Punkt ist, deine eigenen Ressourcen zu schützen. Braucht ein Downstream 30 Sekunden bis zum Timeout, parkt jeder Worker-Thread darauf und dein Service stirbt an etwas, das nicht deine Schuld war. Schiefgehen kann es bei Umfang und Tuning. Wir hatten einen Breaker auf Service-Ebene statt pro Dependency, ein flakiger Empfehlungs-Aufruf hat also den Kreis auch für den Checkout geöffnet, und das war ein deutlich größerer Ausfall als der, den wir verhindern wollten. Die andere Falle ist das Half-Open-Rinnsal. Öffnen alle Replicas gleichzeitig und proben selten, sieht der Downstream fast keinen Traffic, und du bleibst viel länger dunkel, als der eigentliche Fehler gedauert hat.