Circuit-Breaker-Muster für Drittanbieter‑APIs in visuellen Workflows

Warum Ausfälle von Drittanbieter-APIs mehr als ein Feature kaputtmachen\n\nEine einzelne Drittanbieter-API steht oft mitten in alltäglichen Abläufen: Zahlungen abwickeln, Adressen prüfen, Bestand synchronisieren, Nachrichten senden, Identitäten verifizieren. Wenn dieser Anbieter Probleme hat, bricht selten nur ein Button. Ganze Flows können einfrieren, weil sie diese Antwort brauchen, um weiterzukommen.\n\nDeshalb ist ein Circuit-Breaker wichtig. Das ist keine Theorie, sondern eine praktische Methode, um Kernprozesse am Laufen zu halten, selbst wenn eine Integration ungesund ist.\n\nLangsam und ausgefallen schaden unterschiedlich.\n\nWenn eine API langsam ist, versucht Ihr Workflow weiterhin erfolgreich zu sein, aber jeder Schritt wartet. Nutzer sehen drehende Bildschirme, Support bekommt „es hakt“-Tickets und Hintergrundjobs stapeln sich. Langsam ist tückisch, weil es so aussehen kann, als wäre Ihr eigenes System schuld.\n\nWenn eine API ausgefallen ist, erhalten Sie Timeouts oder harte Fehler. Das ist klarer, aber oft gefährlicher, weil Workflows dazu neigen, zu wiederholen. Wenn viele Anfragen gleichzeitig wiederholt werden, entsteht ein Verkehrs-Sturm, der die Wiederherstellung erschwert und Ihr eigenes System mitziehen kann.\n\nTypische Symptome treten schnell auf: Timeouts, weiter wachsende Queues, partielle Aktualisierungen und viel manuelle Nacharbeit.\n\nDer eigentliche Schaden ist die Kettenreaktion. Ist ein Anbieter für Versandkosten langsam, verlangsamt sich die Bestellabwicklung, weil der Workflow die Bestellung ohne ein Angebot nicht bestätigen will. Sind Zahlungen down, kann der Support keine Rückerstattungen ausstellen, obwohl alles andere funktioniert.\n\nSie können nicht so tun, als gäbe es keine Ausfälle. Das Ziel ist, Workflows mit klaren Fallback-Pfaden, temporären Blockierregeln und Alarmierung zu entwerfen, damit das Geschäft weiter Bestellungen annimmt, Kunden bedient und Arbeit aufzeichnet, während die Integration sich erholt.\n\n## Circuit-Breaker in einfachen Worten\n\nEin Circuit-Breaker ist ein Sicherheits-Schalter für API-Aufrufe. Wenn ein Drittanbieter zu versagen beginnt, verhindert der Breaker, dass Ihr Workflow ihn immer wieder bombardiert. Statt einen Ausfall in langsame Bildschirme, Timeouts und feststeckende Jobs zu verwandeln, kontrollieren Sie die Blast-Range.\n\nEin Circuit-Breaker hat drei einfache Ausgänge:\n\n- Den Aufruf erlauben, wenn der Anbieter gesund aussieht.\n- Den Aufruf blockieren, wenn Fehler hoch sind, und sofort einen Fallback-Pfad nehmen.\n- Einen begrenzten Testaufruf erlauben nach einer kurzen Pause, um zu prüfen, ob der Anbieter zurück ist.\n\nWenn Sie Labels bevorzugen: das sind „geschlossen“, „offen“ und „halb-offen“. Die Namen sind nicht der Punkt — Vorhersagbarkeit ist es. Wenn ein Anbieter krank ist, sollte Ihr Workflow jedes Mal gleich reagieren.\n\nDas verschleiert Fehler nicht. Sie zeichnen weiterhin Ausfälle auf, zeigen einen klaren Status für Nutzer oder Ops und alarmieren die richtigen Personen. Sie entscheiden, schnell zu scheitern, Arbeit zu einer sicheren Alternative zu routen oder kurz zu pausieren, bevor erneut getestet wird.\n\n## Wählen Sie, welche API-Aufrufe niemals das Geschäft stoppen dürfen\n\nCircuit-Breaker funktionieren am besten, wenn Sie selektiv sind. Nicht jeder Anbieter-Aufruf verdient besonderen Schutz. Beginnen Sie mit Schritten, die, wenn sie blockiert werden, Geld, Bestellungen oder Kunden-Zugriff stoppen.\n\nEine praktische Methode ist, einer Nutzeranfrage End-to-End zu folgen. Wo würde ein Timeout den Nutzer zwingen, die Aufgabe abzubrechen, oder ein Durcheinander erzeugen, das Ihr Team später aufräumen muss?\n\nTypische Aufrufe, die das Kerngeschäft nicht blockieren dürfen, sind Zahlungen, Versand und Fulfillment, Login/SSO/MFA, OTP- und Bestätigungsnachrichten sowie Compliance-Checks, die an Genehmigungen hängen.\n\nTrennen Sie außerdem nutzerorientierte Schritte von Hintergrund-Jobs. Wartet jemand am Checkout, brauchen Sie eine schnelle Entscheidung: erfolgreich, Fallback oder stoppen mit einer klaren Meldung. Für Hintergrundarbeiten wie das Synchronisieren von Tracking-Nummern sind langsamere Wiederholungen in Ordnung, solange sie den Hauptfluss nie blockieren.\n\nFangen Sie klein an, um Scope Creep zu vermeiden. Schützen Sie zuerst 1–3 Workflows, und erweitern Sie dann.\n\nDefinieren Sie, was „sicherer Fallback“ bedeutet, bevor Sie bauen. Gute Fallbacks sind spezifisch und testbar:\n\n- Zahlungen: speichern Sie die Bestellung als „Zahlung ausstehend“, damit der Warenkorb nicht verloren geht.\n- Versand: nutzen Sie eine zwischengespeicherte Rate, eine Pauschale oder bestätigen Sie die Bestellung und kaufen das Label später.\n- Identität: erlauben Sie Passwort-Login, wenn SSO ausfällt, oder wechseln Sie zu E-Mail-Verifizierung.\n- Messaging: legen Sie SMS in eine Warteschlange und bieten Sie, wo möglich, einen alternativen Pfad an.\n\nIn AppMaster’s Business Process Editor wird das meist zu einem sauberen Zweig: die Kernoperation läuft weiter, während der anbieterabhängige Schritt einen kontrollierten Alternativpfad nimmt.\n\n## Zustände, Schwellen und Timer, die Sie erklären können\n\nEin Circuit-Breaker ist ein Sicherheits-Schalter. Meistens lässt er Aufrufe durch. Wenn der Anbieter zu versagen beginnt, schlägt er um, um Ihren Workflow vor verschwendeter Zeit und Fehler-Aufhäufung zu schützen.\n\n### Die drei Zustände\n\nGeschlossen ist normal. Sie rufen die API auf und machen weiter.\n\nWenn Fehler eine Grenze überschreiten, geht der Breaker Offen. Sie hören auf, den Anbieter für eine kurze Zeit anzurufen und leiten sofort zu einem Fallback (zwischengespeicherter Wert, Warteschlange, alternativer Flow).\n\nNach einer Abkühlzeit geht der Breaker Halb-offen. Sie erlauben eine kleine Anzahl Testaufrufe. Wenn diese erfolgreich sind, schließen Sie wieder. Wenn sie fehlschlagen, öffnen Sie erneut.\n\n### Was zu messen ist\n\nVerwenden Sie Signale, die zeigen, wie der Anbieter versagt:\n\n- Timeouts\n- HTTP-5xx-Fehler\n- Steigende Latenz (zu langsam, um nützlich zu sein)\n- Verbindungs-/DNS-Fehler\n- 429 Rate-Limits\n\nIn einem visuellen Workflow-Tool bilden diese sich meist als einfache Checks ab: Statuscode, verstrichene Zeit und spezifische Fehlerausgaben.\n\n### Anfangsschwellen und die zwei wichtigen Timer\n\nStarten Sie mit Zahlen, die leicht zu erklären sind, und justieren Sie sie anhand des tatsächlichen Traffics. Beispiele:\n\n- Öffnen Sie den Breaker, wenn 5–10 Aufrufe innerhalb von 30–60 Sekunden fehlschlagen.\n- Oder öffnen Sie, wenn 20–40 % der Aufrufe in einem rollenden Fenster fehlschlagen.\n- Behandeln Sie Latenz als Fehler, wenn sie länger ist, als Ihr Prozess toleriert (oft 2–5 Sekunden).\n\nStellen Sie dann zwei Timer ein:\n\n- Cooldown-Zeit (Offen): oft 30 Sekunden bis 5 Minuten.\n- Half-open Testfenster: erlauben Sie 1–5 Testaufrufe oder ein kurzes Zeitfenster wie 10–30 Sekunden.\n\nDas Ziel ist klar: schnell scheitern, wenn der Anbieter ungesund ist, und automatisch wiederherstellen, wenn er zurück ist.\n\n## Schritt-für-Schritt: Einen Circuit-Breaker in einem visuellen Workflow bauen\n\nDie wichtigste Designentscheidung ist, die Frage „Sollten wir den Anbieter jetzt anrufen?“ an einer Stelle zu treffen — nicht über alle Workflows verstreut.\n\n### 1) Packen Sie den Anbieter-Aufruf hinter einen wiederverwendbaren Block\n\nErstellen Sie einen Sub-Prozess (einen wiederverwendbaren Workflow-Block), den jeder Workflow nutzt, wenn er den Anbieter braucht. In AppMaster passt das natürlich zu einem Business Process, den Sie von Endpunkten oder Automationen aufrufen können. Halten Sie ihn eng: Eingaben rein, Anbieteranforderung raus, plus ein klares Erfolgs-/Fehler-Resultat.\n\n### 2) Verfolgen Sie Fehler mit Zeit, nicht nur mit Zählern\n\nSpeichern Sie jedes Ergebnis mit einem Zeitstempel. Halten Sie Dinge wie letzte erfolgreiche Anfrage, letzter Fehler, Fehler innerhalb eines Fensters, aktuellen Zustand und eine Cooldown-Deadline fest.\n\nPersistieren Sie diese Felder in einer Tabelle, damit der Breaker Neustarts überlebt und über mehrere Instanzen konsistent bleibt. PostgreSQL via Data Designer passt dafür gut.\n\n### 3) Definieren Sie Zustandsänderungen, denen Sie jedes Mal folgen\n\nHalten Sie die Regeln simpel. Beispiel: Wenn 5 Fehler innerhalb von 2 Minuten auftreten, wechseln Sie zu Offen. Während Offen überspringen Sie den Anbieter-Aufruf, bis die Cooldown-Zeit abgelaufen ist. Nach Cooldown gehen Sie zu Halb-offen und erlauben einen kontrollierten Versuch. Gelingt er, schließen Sie. Scheitert er, öffnen Sie wieder.\n\n### 4) Verzweigen Sie den Workflow: Anbieter-Pfad vs. Fallback-Pfad\n\nPrüfen Sie vor dem Anbieter-Aufruf den gespeicherten Zustand:\n\n- Geschlossen: rufen Sie den Anbieter an und aktualisieren Erfolg oder Fehler.\n- Offen: überspringen Sie den Aufruf und führen den Fallback aus.\n- Halb-offen: erlauben Sie einen begrenzten Versuch und entscheiden Sie dann, ob Sie schließen oder erneut öffnen.\n\nBeispiel: Wenn eine Versandlabel-API down ist, kann der Fallback die Bestellung mit dem Status „Label pending“ anlegen und einen Retry-Job einreihen, statt Checkout oder Lagerarbeit zu blockieren.\n\n### 5) Teilen Sie den Breaker über Workflows hinweg\n\nHaben Sie mehrere Workflows und Server, müssen alle den gleichen Breaker-Zustand lesen und schreiben. Sonst kann eine Instanz den Anbieter weiter bombardieren, während eine andere bereits pausiert hat.\n\n## Fallback-Pfade, die Arbeit weiterlaufen lassen\n\nEin Circuit-Breaker hilft nur, wenn Sie entscheiden, was passiert, wenn der Aufruf blockiert wird. Ein guter Fallback lässt den Nutzer weitermachen, schützt Ihre Daten und macht spätere Nacharbeiten vorhersehbar.\n\nWählen Sie einen Fallback passend zur Aufgabe. Wenn ein Versandraten-Anbieter ausfällt, brauchen Sie nicht immer den exakten Preis, um die Bestellung anzunehmen. In einem visuellen Workflow routen Sie den fehlgeschlagenen API-Schritt in einen Fallback-Zweig, der dennoch ein brauchbares Ergebnis liefert.\n\nIn der Praxis sehen Fallbacks meist so aus:\n\n- Einen zuletzt bekannten Wert cachen (mit klarer Frischebegrenzung).\n- Eine sichere Standard-Schätzung nutzen, deutlich gekennzeichnet.\n- Zur manuellen Prüfung routen.\n- Die Arbeit für später zum Retry in die Warteschlange stellen (asynchron).\n\nDie Nutzererfahrung ist genauso wichtig wie die Logik. Zeigen Sie keinen vagen Fehler. Sagen Sie, was passiert ist und was der Nutzer als Nächstes tun kann: „Wir konnten die Rate gerade nicht bestätigen. Sie können die Bestellung mit geschätzten Versandkosten aufgeben oder sie zur Prüfung speichern.“\n\nPlanen Sie außerdem für kurze vs. lange Ausfälle. Ein kurzer Ausfall (Minuten) bedeutet oft „weiterlaufen, im Hintergrund wiederholen“. Ein längerer Ausfall (Stunden) kann strengere Maßnahmen erfordern, wie mehr manuelle Prüfungen oder Freigaben.\n\nVerfolgen Sie jeden Fallback, damit die Nachbearbeitung einfach ist. Mindestens sollten Sie Fallback-Typ, ursprüngliche Anfrage-Daten, was dem Nutzer zurückgegeben wurde (und ob es eine Schätzung war) sowie einen Status für Follow-up protokollieren.\n\n## Temporäre Blockierregeln und intelligentere Retries\n\nUnkontrollierte Retries verwandeln kleine Anbieter-Störungen in echte Ausfälle. Wenn viele Workflows gleichzeitig wiederholen, entsteht ein Spike (das „thundering herd“-Problem). Der Anbieter wird langsamer, Ihre Queues wachsen und Sie verbrauchen Rate-Limits.\n\nRetries sollten vorhersehbar und begrenzt sein und den Breaker-Zustand respektieren. Eine praktische Richtlinie ist:\n\n- Halten Sie max. Retries niedrig (oft 2–3).\n- Nutzen Sie exponentielles Backoff (z. B. 2s, 8s, 30s).\n- Fügen Sie Jitter hinzu, damit Retries nicht synchron laufen.\n- Begrenzen Sie die Gesamt-Retry-Zeit (z. B. 60–90 Sekunden).\n- Ist der Breaker Offen, nicht erneut versuchen — direkt zum Fallback.\n\nTemporäres Blockieren ist verwandt, aber unterscheidbar. Es gilt, wenn die Antwort sagt „das funktioniert gerade nicht“. Übliche Regeln:\n\n- 429 Rate-Limit: blockieren Sie für die Retry-After-Periode (oder ein sicheres fixes Fenster).\n- 401/403 Auth-Fehler: blockieren Sie, bis Zugangsdaten erneuert sind, und testen Sie dann einmal.\n- Konsequente 5xx: blockieren Sie kurz und erlauben dann einen kleinen Test.\n\nWährend einer Blockade entscheiden Sie, was mit bereits laufender Arbeit passiert: in die Warteschlange, umleiten oder degradiert weiterverarbeiten (z. B. Bestellung annehmen, aber „SMS versenden“ verzögern).\n\n## Alerting, das sagt, was zu tun ist\n\nEin Circuit-Breaker hilft nur, wenn Menschen schnell davon erfahren und wissen, was zu tun ist. Das Ziel ist kein Rauschen, sondern eine klare Nachricht, wenn sich das Verhalten ändert: Aufrufe werden blockiert, Fallbacks sind aktiv oder der Breaker ist länger als erwartet offen.\n\nGute Standard-Trigger:\n\n- Alarm, wenn der Breaker öffnet.\n- Alarm, wenn er länger als eine vorgegebene Zeit offen bleibt.\n- Alarm bei starkem Anstieg von Fehlern, noch bevor er öffnet.\n\nMachen Sie Alerts handlungsfähig. Nennen Sie Anbieter und Endpoint, aktuellen Zustand und wann er sich änderte, was Nutzer spüren, was der Workflow gerade tut (blockiert, wiederholt, Fallback), und einen vorgeschlagenen nächsten Schritt.\n\nLeiten Sie Alerts nach Schwere. Eine nicht-kritische Enrichment-API kann per E-Mail gehen. Zahlungen, Login oder Bestellübermittlung verdienen normalerweise Pager. In AppMaster lässt sich das sauber abbilden mit Zweigen, die E-Mail, Telegram oder SMS basierend auf einer Schwere-Flag senden.\n\nVerfolgen Sie eine kleine Metrik-Auswahl, damit Sie sehen, ob Sie sich erholen: Blockierte Aufrufe und Fallback-Nutzung pro Anbieter reichen oft aus.\n\n## Beispiel-Szenario: Anbieter-Ausfall ohne Bestellstopp\n\nEin häufiger Fehler: Ihr Versandraten-Anbieter fällt genau dann aus, wenn Kunden im Checkout sind. Wenn Ihr Workflow während der Bestellerstellung auf Live-Raten besteht, kann ein einziger Ausfall Bestellungen komplett stoppen.\n\nAn einem normalen Tag wird die Bestellung erstellt, dann fragt der Workflow Live-Raten an und die Bestellung wird mit dem gewählten Carrier und Preis gespeichert.\n\nWenn der Anbieter zu versagen beginnt, laufen Aufrufe in Timeouts oder liefern 5xx-Fehler. Sobald Ihr Schwellenwert erreicht ist (z. B. 5 Fehler in 2 Minuten), öffnet der Breaker.\n\nWährend Offen stoppt der Workflow für ein kurzes Fenster (z. B. 10 Minuten) Aufrufe an den Versandanbieter. Das verhindert, dass ein fehlernder Anbieter den Checkout für alle blockiert.\n\nStatt den Checkout zu blockieren, kann der Fallback:\n\n- Eine Pauschale anwenden (oder eine sichere Schätzung).\n- Die Bestellung trotzdem anlegen.\n- Sie als „Shipping rate pending“ markieren für spätere Neuberechnung.\n- Anbieter-Fehlerdetails zum Nachverfolgen speichern.\n\nIn AppMaster ist das ein klarer Zweig im Business Process Editor, gestützt durch Data Designer-Felder wie shipping_rate_status und shipping_rate_source.\n\n## Schnelle Checks vor dem Go-Live\n\nEin Circuit-Breaker sollte unter Last genauso reagieren wie in einer Demo. Vor dem Release prüfen Sie die Basics:\n\n- Schwellen und Cooldowns sind dokumentiert und leicht änderbar.\n- Der offene Zustand blockiert Aufrufe sofort (ohne bloß auf Anbieter-Timeouts zu warten).\n- Fallback-Verhalten ist sicher in Bezug auf Geld und Kunden-Versprechen.\n\n- Halb-offen-Probing ist auf wenige Testaufrufe beschränkt.\n\n- Logs machen Zeitpunkt und Impact leicht beantwortbar.\n\nVerbringen Sie extra Zeit auf Fallback-Sicherheit. Ein Fallback, der „Arbeit weiterlaufen lässt“, kann auch finanzielles Risiko erzeugen. Ist der Zahlungsanbieter down, ist es gefährlich, Bestellungen als bezahlt zu markieren. Eine sicherere Vorgehensweise ist „Zahlung ausstehend“, mit klarer Kundenkommunikation.\n\nTesten Sie die Wiederherstellung gezielt. Erzwingen Sie Fehler, beobachten Sie, wie der Breaker öffnet, warten Sie die Cooldown-Zeit ab und bestätigen Sie, dass Halb-offen nur eine kleine Probe sendet. Gelingt sie, sollte der Breaker schnell schließen. Scheitert sie, sollte er wieder öffnen, ohne den Anbieter zu fluten.\n\nIhre Logs sollten in unter einer Minute beantworten können: Wer war betroffen, wann begann es, welcher Workflow-Schritt hat den Breaker ausgelöst und welcher Fallback wurde genutzt.\n\n## Nächste Schritte: Das Muster in AppMaster implementieren\n\nWählen Sie eine Integration, die den täglichen Betrieb stark gefährdet, wenn sie ausfällt (Zahlungen, Versand-Labels, SMS, CRM-Sync). Bauen Sie den Breaker End-to-End für genau diesen Aufruf zuerst. Wenn das Team dem Verhalten vertraut, wiederholen Sie die gleiche Vorlage für den nächsten Anbieter.\n\nIn AppMaster modellieren Sie den Breaker-Zustand in PostgreSQL mit dem Data Designer. Halten Sie es einfach: ein Datensatz pro Anbieter (oder Endpoint) mit Feldern wie state, failure_count, last_failure_at, open_until und einem kurzen last_error.\n\nImplementieren Sie dann die Logik im Business Process Editor mit gut lesbaren Verzweigungen. Klarheit schlägt Cleverness.\n\nEine praktische Build-Reihenfolge:\n\n1. Prüfen Sie den Breaker-Zustand und blockieren Sie Aufrufe, wenn open_until in der Zukunft liegt.\n2. Rufen Sie die Anbieter-API auf und erfassen Sie sowohl Erfolg als auch Fehlerausgaben.\n3. Bei Erfolg: Zähler zurücksetzen und Breaker schließen.\n4. Bei Fehler: Zähler erhöhen und Breaker öffnen, wenn Schwellen erreicht sind.\n5. Routen Sie nutzergerichtete Flows zu einem Fallback (Warteschlange, zwischengespeicherte Daten oder manuelle Verarbeitung).\n\nDokumentieren Sie die Fallback-Entscheidung in einfacher Sprache, damit Support und Ops wissen, was Nutzer sehen.\n\nWenn der Breaker öffnet, benachrichtigen Sie einen Owner mit den Messaging-Modulen von AppMaster (E-Mail, SMS, Telegram). Fügen Sie die relevanten Infos bei: Anbieter, Endpoint, Zustand und die erste empfohlene Maßnahme.\n\nWenn Sie diese Workflows in AppMaster bauen, ist appmaster.io ein praktischer Einstiegspunkt, weil derselbe visuelle Business Process Endpunkte, Hintergrund-Jobs und Alerting mit einem gemeinsamen Breaker-Zustand treiben kann.