Circuit breaker-patroon voor derde-partij API's in visuele workflows

Waarom storingen bij derde-partij API's meer dan één functie breken

Een enkele derde-partij API zit vaak middenin het dagelijkse werk: betalingen verwerken, adressen controleren, inventaris synchroniseren, berichten verzenden, identiteit verifiëren. Wanneer die leverancier problemen heeft, breekt zelden slechts één knop. Het kan hele flows bevriezen die die reactie nodig hebben om door te gaan.

Daarom is een circuit breaker belangrijk. Het is geen theorie. Het is een praktische manier om kernactiviteiten draaiende te houden, zelfs wanneer een integratie ongezond is.

Traag en down schaden op verschillende manieren.

Als een API traag is, probeert je workflow nog steeds te slagen, maar elke stap wacht. Gebruikers zien draaiende schermen, supportteams krijgen “het hangt” tickets en achtergrondjobs lopen op. Traagheid is lastig omdat het kan lijken alsof je eigen systeem faalt.

Wanneer een API down is, krijg je time-outs of harde fouten. Dat is duidelijker, maar vaak gevaarlijker omdat workflows geneigd zijn te retryen. Wanneer veel verzoeken tegelijk opnieuw proberen, creëer je een verkeersstorm die herstel bemoeilijkt en je eigen systeem kan mee naar beneden trekken.

Veelvoorkomende symptomen verschijnen snel: time-outs, rijen die blijven groeien, gedeeltelijke updates en veel handmatig opruimwerk.

De echte schade is de kettingreactie. Als een provider voor verzendtarieven traag is, vertraagt de bestelling omdat de workflow weigert de order te bevestigen zonder een quote. Als betalingen down zijn, kan support worden geblokkeerd om terugbetalingen uit te voeren, ook al werkt de rest van het systeem.

Je kunt niet doen alsof storingen niet bestaan. Het doel is workflows te ontwerpen met duidelijke fallback-paden, tijdelijke blokkeringregels en alerting zodat het bedrijf bestellingen kan blijven aannemen, klanten kan bedienen en werk kan vastleggen terwijl de integratie herstelt.

Circuit breaker in eenvoudige bewoordingen

Een circuit breaker is een veiligheidschakelaar voor API-aanroepen. Wanneer een derde-partij service begint te falen, voorkomt de breaker dat je workflow die service keer op keer blijft bombarderen. In plaats van één storing te veranderen in draaiende schermen, time-outs en vastlopende jobs, bepaal je zelf de impact.

Een circuit breaker heeft drie eenvoudige uitkomsten:

• Sta de aanroep toe wanneer de leverancier gezond lijkt.
• Blokkeer de aanroep wanneer fouten hoog zijn en neem onmiddellijk een fallbackpad.
• Probeer een beperkte testaanroep na een korte pauze om te zien of de leverancier terug is.

Als je liever labels gebruikt: dat zijn “gesloten,” “open” en “half-open.” De namen zijn niet het belangrijkste. Voorspelbaarheid wel. Wanneer een vendor ziek is, moet je workflow elke keer op dezelfde manier reageren.

Dit verbergt fouten niet. Je registreert nog steeds mislukkingen, toont een duidelijke status aan gebruikers of ops en waarschuwt de juiste mensen. Je kiest ervoor om snel te falen, werk naar een veiliger alternatief te routeren of even te pauzeren voordat je opnieuw test.

Kies welke API-aanroepen nooit het bedrijf mogen stoppen

Circuit breakers werken het beste wanneer je selectief bent. Niet elke vendor-aanroep verdient speciale bescherming. Begin met stappen die, als ze worden geblokkeerd, geld, bestellingen of klanttoegang stoppen.

Een praktische methode is om één gebruikersverzoek end-to-end te volgen. Waar zou een time-out de gebruiker dwingen de taak te staken, of een rommel creëren die je team later moet opruimen?

Typische “mogen het werk niet blokkeren”-aanroepen zijn betalingen, verzending en fulfilment, login/SSO/MFA, OTP- en bevestigingsberichten, en compliance-checks gekoppeld aan goedkeuring.

Split ook user-facing stappen van achtergrondjobs. Als iemand wacht op een checkout-scherm, heb je een snelle beslissing nodig: slagen, fallback of stoppen met een duidelijke melding. Voor achtergrondwerk zoals het synchroniseren van trackingnummers zijn langzamere retries prima, zolang ze het hoofdproces niet blokkeren.

Begin klein om scope creep te vermijden. Bescherm eerst 1–3 workflows en breid daarna uit.

Definieer wat een “veilige fallback” betekent voordat je iets bouwt. Goede fallbacks zijn specifiek en testbaar:

• Betalingen: sla de bestelling op als “betaling in afwachting” zodat de winkelwagen niet verloren gaat.
• Verzending: gebruik een gecachte tarief, een flat rate of bevestig de bestelling en stel het kopen van het label uit.
• Identiteit: sta wachtwoordlogin toe wanneer SSO down is, of schakel over naar e-mailverificatie.
• Messaging: zet SMS in de wachtrij voor later en bied een alternatief pad wanneer mogelijk.

In AppMaster’s Business Process Editor wordt dit meestal een duidelijke branch: de kernoperatie gaat door, terwijl de vendor-afhankelijke stap een gecontroleerd alternatief neemt.

Statussen, drempels en timers die je kunt uitleggen

Een circuit breaker is een veiligheidschakelaar. Meestal laat hij aanroepen door. Wanneer de vendor begint te falen, schakelt hij om om je workflow te beschermen tegen verspilde tijd en opgestapelde fouten.

De drie statussen

Gesloten is normaal. Je roept de API aan en gaat verder.

Als fouten een grens overschrijden, gaat de breaker Open. Je stopt met het aanroepen van de vendor voor een korte periode en routeert direct naar een fallback (gecachede waarde, uitgestelde taak, alternatief pad).

Na een cooldown gaat de breaker naar Half-open. Je staat een klein aantal testaanroepen toe. Als die slagen, ga je terug naar Gesloten. Als ze falen, ga je terug naar Open.

Wat te meten

Gebruik signalen die overeenkomen met hoe de vendor faalt:

• Time-outs
• HTTP 5xx fouten
• Stijgende latency (te traag om nuttig te zijn)
• Verbinding-/DNS-fouten
• 429 rate limits

In een visuele workflow-tool vertalen deze zich meestal naar eenvoudige checks: statuscode, verstreken tijd en specifieke foutoutputs.

Startdrempels en de twee sleutel-timers

Begin met getallen die makkelijk uit te leggen zijn en stem ze daarna af op basis van echt verkeer. Voorbeelden:

• Open de breaker als 5–10 aanroepen falen binnen 30–60 seconden.
• Of open als 20%–40% van de aanroepen faalt in een rollend venster.
• Behandel latency als een fout wanneer deze hoger is dan wat je proces kan verdragen (vaak 2–5 seconden).

Stel dan twee timers in:

• Cooldowntijd (Open state): vaak 30 seconden tot 5 minuten.
• Half-open testvenster: sta 1–5 testaanroepen toe, of een kort tijdvenster zoals 10–30 seconden.

Het doel is eenvoudig: snel falen wanneer de vendor ongezond is en automatisch herstellen wanneer die het weer doet.

Stapsgewijs: bouw een circuit breaker in een visuele workflow

De belangrijkste ontwerpskeuze is om de “moeten we nu de vendor aanroepen?” beslissing op één plek te maken, niet verspreid over elke workflow.

1) Zet de vendor-aanroep achter één herbruikbaar blok

Maak één subproces (een herbruikbaar workflowblok) dat elke workflow gebruikt wanneer het die vendor nodig heeft. In AppMaster komt dit natuurlijk neer op een Business Process dat je kunt aanroepen vanuit endpoints of automatiseringen. Houd het smal: input erin, vendorrequest eruit, plus een duidelijke succes/fout uitkomst.

2) Volg fouten met tijd, niet alleen aantallen

Registreer elke uitkomst met een timestamp. Sla zaken op zoals laatste succes, laatste fout, fouten binnen een venster, huidige status en een cooldown-deadline.

Bewaar deze velden in een tabel zodat de breaker restarts overleeft en consistent blijft over meerdere instanties. PostgreSQL via Data Designer past hier goed bij.

3) Definieer statusveranderingen die je elke keer volgt

Houd de regels simpel. Voorbeeld: als 5 fouten binnen 2 minuten optreden, schakel naar Open. Terwijl Open, sla je de vendor-aanroep over totdat de cooldown verstrijkt. Na cooldown ga je Half-open en sta je één gecontroleerde poging toe. Als die lukt, sluit je de breaker. Als die faalt, open je hem weer.

4) Branch de workflow: vendorpad vs fallbackpad

Controleer vóór de vendor-aanvraag de opgeslagen status:

• Gesloten: roep de vendor aan en werk succes of fout bij.
• Open: sla de aanroep over en voer de fallback uit.
• Half-open: sta een beperkte poging toe en beslis of je sluit of weer opent.

Voorbeeld: als een API voor verzendlabels down is, kan de fallback de bestelling aanmaken met de status “Label pending” en een retry-job in de wachtrij zetten, in plaats van de checkout of magazijnwerk te blokkeren.

5) Maak het gedeeld voor alle workflows

Als je meerdere workflows en servers hebt, moeten ze dezelfde breaker-status lezen en schrijven. Anders kan de ene instantie de vendor blijven belasten terwijl een andere al heeft besloten te pauzeren.

Fallback-paden die werk laten doorgaan

Een circuit breaker helpt alleen als je bepaalt wat er gebeurt wanneer de aanroep geblokkeerd wordt. Een goede fallback houdt de gebruiker bezig, beschermt je data en maakt later reconciliatie voorspelbaar.

Kies een fallback die past bij de taak. Als een verzendtarief-provider down is, heb je vaak geen exact tarief nodig om de bestelling te accepteren. In een visuele workflow routeer je de mislukte API-stap naar een fallback-branch die toch een bruikbaar resultaat oplevert.

In de praktijk zien fallbacks er meestal zo uit:

• Gebruik een laatste bekende gecachte waarde (met een duidelijke frisheidsperiode).
• Gebruik een veilige standaardraming, duidelijk gelabeld.
• Routeer naar handmatige beoordeling.
• Zet het werk in de wachtrij voor later retry (async job).

De gebruikerservaring is minstens zo belangrijk als de logica. Laat geen vage foutmelding zien. Zeg wat er gebeurde en wat de gebruiker kan doen: “We konden de tariefbevestiging nu niet krijgen. Je kunt de bestelling plaatsen met een geschat verzendbedrag, of deze bewaren voor review.”

Plan ook voor korte versus lange storingen. Een korte storing (minuten) betekent vaak “ga door, retry op de achtergrond.” Een langere storing (uren) kan striktere maatregelen vereisen zoals meer handmatige beoordeling of goedkeuringen.

Registreer uiteindelijk elke fallback zodat reconciliatie eenvoudig is. Noteer op zijn minst het fallback-type, originele verzoekdetails, wat je de gebruiker teruggaf (en of het een schatting was) en een status voor opvolging.

Tijdelijke blokkeringregels en slim retryen

Ongecontroleerde retries veranderen kleine vendor-hiccups in echte storingen. Wanneer veel workflows tegelijk opnieuw proberen, ontstaat er een piek (het “thundering herd”-probleem). De vendor wordt trager, je queues groeien en je gebruikt rate limits op.

Retries moeten voorspelbaar en beperkt zijn, en ze moeten de breaker-status respecteren. Een praktische policy is:

• Houd max retries laag (vaak 2–3).
• Gebruik exponentiële backoff (bijv. 2s, 8s, 30s).
• Voeg jitter toe zodat retries niet synchroon lopen.
• Beperk totale retry-tijd (bijv. 60–90 seconden).
• Als de breaker Open is, retry dan niet. Ga direct naar fallback.

Tijdelijke blokkering is gerelateerd maar onderscheidend. Het is voor gevallen waarin de respons je vertelt “dit werkt nu niet.” Veelvoorkomende regels:

• 429 rate limit: blokkeer voor de Retry-After-periode (of een veilige vaste window).
• 401/403 auth-fout: blokkeer totdat credentials vernieuwd zijn en test daarna één keer.
• Constante 5xx: blokkeer kort en laat daarna een kleine test toe.

Tijdens een blokkade bepaal je wat er met lopend werk gebeurt: zet het in de wachtrij, routeer het om of degradeer gracieus (bijv. accepteer de bestelling maar stel “stuur SMS” uit).

Alerting die zegt wat je moet doen

Een circuit breaker helpt alleen als mensen er snel van horen en weten wat te doen. Het doel is geen ruis. Het is één duidelijke boodschap wanneer gedrag verandert: aanroepen worden geblokkeerd, fallbacks zijn actief of de breaker is langer open dan verwacht.

Goede standaard triggers:

• Alert wanneer de breaker opent.
• Alert als hij langer open blijft dan een tijdslimiet.
• Alert bij een scherpe stijging van fouten, zelfs voordat hij opent.

Maak alerts actiegericht. Voeg vendor en endpoint toe, huidige status en wanneer die veranderde, wat gebruikers voelen, wat de workflow nu doet (blocken, retryen, fallback), en één voorgestelde volgende stap.

Routeer alerts op ernst. Een niet-kritische enrichment API kan naar e-mail; betalingen, login of orderverzending verdienen meestal een page. In AppMaster vertaalt dit zich gemakkelijk naar branches die e-mail, Telegram of SMS sturen op basis van een severity-flag.

Houd een kleine set metrics bij zodat je kunt zien of je herstelt: geblokkeerde aanroepen en fallback-gebruik per vendor zijn vaak genoeg.

Voorbeeldscenario: vendorstoring zonder bestellingen te stoppen

Een veelvoorkomende fout: je verzendtarief-provider valt uit precies wanneer klanten afrekenen. Als je workflow live tarieven vereist bij ordercreatie, kan één storing bestellingen volledig stoppen.

Op een normale dag wordt de bestelling aangemaakt, vervolgens vraagt de workflow live tarieven op en wordt de order opgeslagen met de gekozen carrier en prijs.

Wanneer de vendor begint te falen, time-outs of 5xx-fouten optreden. Zodra je drempel is bereikt (bijv. 5 fouten in 2 minuten), opent de breaker.

Terwijl Open roept de workflow de verzendprovider niet meer aan voor een korte periode (bijv. 10 minuten). Dat voorkomt dat een falende vendor de checkout voor iedereen saboteert.

In plaats van de checkout te blokkeren, kan de fallback:

• Een flat-rate toepassen (of een veilige schatting).
• De bestelling toch aanmaken.
• Markeren als “Shipping rate pending” voor latere herberekening.
• Vendor-foutdetails opslaan voor opvolging.

In AppMaster is dit een duidelijke tak in de Business Process Editor, ondersteund door Data Designer-velden zoals shipping_rate_status en shipping_rate_source.

Snelle checks voordat je live gaat

Een circuit breaker moet zich onder stress hetzelfde gedragen als in een demo. Controleer vóór release de basis:

• Drempels en cooldowns zijn gedocumenteerd en makkelijk aan te passen.
• Open status blokkeert aanroepen onmiddellijk (zonder te wachten op vendor time-outs).
• Fallback-gedrag is veilig voor geld en klantbeloften.
• Half-open probing is beperkt tot een paar testaanroepen.
• Logs maken timing en impact makkelijk te beantwoorden.

Besteed extra aandacht aan fallback-veiligheid. Een fallback die “werk laat doorgaan” kan ook financieel risico creëren. Als de betalingsprovider down is, is bestellingen als betaald markeren gevaarlijk. Een veiliger aanpak is “betaling in afwachting” met duidelijke klantcommunicatie.

Test herstel doelbewust. Forceer fouten, kijk of de breaker opent, wacht de cooldown af en bevestig dat Half-open alleen een kleine probe stuurt. Als die slaagt, moet hij snel sluiten. Als die faalt, moet hij zonder het vendor te overspoelen weer openen.

Je logs moeten binnen een minuut antwoord geven op: wie was er getroffen, wanneer begon het, welke workflowstap veroorzaakte de breaker en welke fallback werd gebruikt.

Volgende stappen: implementeer het patroon in AppMaster

Kies één integratie die dagelijkse operaties kan schaden als deze faalt (betalingen, verzendlabels, SMS, CRM-sync). Bouw de breaker end-to-end voor die enkele aanroep eerst. Zodra het team het gedrag vertrouwt, herhaal je dezelfde template voor de volgende vendor.

In AppMaster modelleer je breaker-status in PostgreSQL met Data Designer. Houd het eenvoudig: één record per vendor (of endpoint) met velden zoals state, failure_count, last_failure_at, open_until en een korte last_error.

Implementeer daarna de logica in de Business Process Editor met leesbare branches. Helderheid verslaat slimheid.

Een praktische bouwvolgorde:

1. Controleer breaker-status en blokkeer aanroepen wanneer open_until in de toekomst ligt.
2. Roep de vendor-API aan en capture zowel succes- als foutoutputs.
3. Bij succes: reset counters en sluit de breaker.
4. Bij fout: verhoog counters en open de breaker wanneer drempels worden bereikt.
5. Routeer user-facing flows naar een fallback (queue werk, gebruik gecachte data of sta handmatige verwerking toe).

Documenteer de fallback-beslissing in gewone taal zodat support en ops weten wat gebruikers zien.

Wanneer de breaker opent, waarschuw een eigenaar met de messaging-modules van AppMaster (e-mail, SMS, Telegram). Voeg toe wat ertoe doet: vendor, endpoint, status en de eerste aanbevolen actie.

Als je deze workflows in AppMaster bouwt, is appmaster.io een praktische plek om te beginnen omdat hetzelfde visuele Business Process endpoints, achtergrondjobs en alerting kan aandrijven met één gedeelde breaker-status.