Gebeutenisgestuurde workflows versus request-response API's voor langdurige taken

Waarom langdurige processen lastig zijn in bedrijfsapps

Een proces is “langdurig” wanneer het niet in één snelle stap klaar kan zijn. Het kan minuten, uren of dagen duren omdat het afhankelijk is van mensen, tijd of externe systemen. Alles met goedkeuringen, overdrachten en wachten valt in deze categorie.

Daar begint eenvoudig request-response API-denken te haperen. Een API-aanroep is gebouwd voor een korte uitwisseling: stuur een verzoek, krijg een antwoord, ga door. Lange taken zijn meer als een verhaal met hoofdstukken. Je moet pauzeren, precies onthouden waar je bent en later verdergaan zonder te gokken.

Je ziet dit in alledaagse bedrijfsapps: inkoopgoedkeuringen die manager en financiën nodig hebben, onboarding van medewerkers die wacht op documentcontroles, terugbetalingen die afhangen van een betalingsprovider, of toegangaanvragen die beoordeeld en vervolgens toegepast moeten worden.

Wanneer teams een lang proces behandelen als één enkele API-call, ontstaan een paar voorspelbare problemen:

• De app verliest status na een herstart of deploy en kan niet betrouwbaar hervatten.
• Retries veroorzaken duplicaten: een tweede betaling, een tweede e-mail, een dubbele goedkeuring.
• Eigenaarschap wordt vaag: niemand weet of de aanvrager, een manager of een systeemtaak hierna moet handelen.
• Support heeft geen zicht en kan niet zonder in logs te duiken zeggen “waar zit het vast?”.
• Wachttijdlogica (timers, herinneringen, deadlines) eindigt als fragiele achtergrond-scripts.

Een concreet scenario: een medewerker vraagt softwaretoegang aan. De manager keurt snel goed, maar IT heeft twee dagen nodig om het te provisionen. Als de app processtatus, herinneringen en veilig hervatten niet kan beheersen, krijg je handmatige follow-ups, verwarde gebruikers en extra werk.

Daarom doet de keuze tussen evenementgestuurde workflows en request-response API's er toe voor langdurige bedrijfsprocessen.

Twee denkkaders: synchrone calls versus events over tijd

De eenvoudigste vergelijking komt neer op één vraag: is het werk af terwijl de gebruiker wacht, of gaat het door nadat hij weg is?

Een request-response API is één uitwisseling: één call in, één response uit. Het past bij werk dat snel en voorspelbaar afloopt, zoals het aanmaken van een record, het berekenen van een offerte of het controleren van voorraad. De server doet het werk, geeft succes of fout terug en de interactie is voorbij.

Een gebeurtenisgestuurde workflow is een reeks reacties over tijd. Er gebeurt iets (een order is aangemaakt, een manager keurt goed, een timer verloopt) en de workflow gaat naar de volgende stap. Dit model past bij werk met overdrachten, wachten, retries en herinneringen.

Het praktische verschil is status.

Bij request-response leeft status vaak in het huidige verzoek plus servergeheugen tot de response wordt verzonden. Bij gebeurtenisgestuurde workflows moet status opgeslagen worden (bijvoorbeeld in PostgreSQL) zodat het proces later kan hervatten.

Foutafhandeling verandert ook. Request-response behandelt fouten meestal door een fout terug te geven en de client te vragen het opnieuw te proberen. Workflows leggen de fout vast en kunnen veilig opnieuw proberen wanneer de omstandigheden verbeteren. Ze kunnen ook elke stap als een event loggen, waardoor de geschiedenis makkelijker te reconstrueren is.

Een simpel voorbeeld: “Verstuur onkostennota” kan synchroon. “Krijg goedkeuring, wacht 3 dagen, herinner manager, betaal daarna” is dat niet.

Goedkeuringen: hoe elk model menselijke beslissingen aanpakt

Goedkeuringen zijn waar langdurig werk echt worden. Een systeemstap is in milliseconden klaar, maar een persoon kan in twee minuten of twee dagen antwoorden. De sleutel is of je dat wachten modelleert als een gepauzeerd proces, of als een nieuw bericht dat later binnenkomt.

Bij request-response API's krijgen goedkeuringen vaak een onhandige vorm:

• Blokkeren (niet praktisch)
• Polling (de client vraagt steeds “goedgekeurd?”)
• Callbacks/webhooks (de server belt je later terug)

Dit kan werken, maar het voegt infrastructuur toe alleen om “menselijke tijd” met “API-tijd” te verbinden.

Met events leest de goedkeuring als een verhaal. De app legt iets vast als “ExpenseSubmitted”, en ontvangt later “ExpenseApproved” of “ExpenseRejected”. De workflow-engine (of je eigen state machine) verplaatst het record pas wanneer het volgende event binnenkomt. Dit komt overeen met hoe mensen meestal over zakelijke stappen denken: indienen, beoordelen, beslissen.

Complexiteit verschijnt snel bij meerdere goedkeurders en escalatieregels. Je kunt zowel een manager als financiën nodig hebben, maar ook een senior manager toestaan te overrulen. Als je die regels niet duidelijk modelleert, wordt het proces moeilijk te begrijpen en nog moeilijker te auditen.

Een eenvoudig goedkeuringsmodel dat schaalt

Een praktisch patroon is één "request"-record te bewaren en beslissingen apart op te slaan. Zo kun je veel goedkeurders ondersteunen zonder de kernlogica te herschrijven.

Leg een paar gegevens als eersteklas records vast:

• De goedkeuringsaanvraag zelf: wat wordt goedgekeurd en de huidige status
• Individuele beslissingen: wie besliste, goedgekeurd/afgewezen, tijdstempel, reden
• Vereiste goedkeurders: rol of persoon, en eventuele orderregels
• Uitkomstregels: “een van”, “meerderheid”, “alle vereiste”, “override toegestaan”

Welke implementatie je ook kiest, sla altijd vast wie wat goedkeurde, wanneer en waarom als data, niet slechts als een logregel.

Timers en wachten: herinneringen, deadlines en escalaties

Wachten is waar lange taken rommelig beginnen te voelen. Mensen gaan lunchen, agenda's lopen vol en “we komen erop terug” verandert in “wie is hier nu eigenaar?” Dit is een van de duidelijkste verschillen tussen gebeurtenisgestuurde workflows en request-response API's.

Bij request-response API's is tijd ongemakkelijk. HTTP-calls hebben timeouts, dus je kunt een verzoek niet twee dagen openhouden. Teams eindigen vaak met patronen zoals polling, een aparte geplande taak die de database scant, of handmatige scripts wanneer iets overdue is. Dit kan werken, maar de wachttijdlogica leeft buiten het proces. Randgevallen zijn makkelijk te missen, bijvoorbeeld wanneer de job twee keer draait of wanneer het record vlak voor een reminder veranderde.

Workflows behandelen tijd als een normale stap. Je kunt zeggen: wacht 24 uur, stuur een herinnering, wacht dan tot 48 uur totaal en escaleer naar een andere goedkeurder. Het systeem bewaart status, dus deadlines zijn niet verborgen in een apart “cron + queries”-project.

Een eenvoudige regel kan zo lezen:

Na indienen van een onkostennota, wacht 1 dag. Als de status nog “Pending” is, bericht de manager. Na 2 dagen, als het nog pending is, wijs het toe aan de leiding van de manager en leg de escalatie vast.

Het cruciale detail is wat je doet wanneer de timer afgaat maar de wereld veranderd is. Een goede workflow controleert altijd de huidige status voor het handelen:

• Laad de laatste status
• Bevestig dat het nog pending is
• Bevestig dat de toegewezen persoon nog geldig is (teams veranderen)
• Leg vast wat je besloot en waarom

Retries en foutherstel zonder dubbele acties

Retries zijn wat je doet wanneer iets faalt om redenen buiten je volledige controle: een payment gateway time-out, een e-mailprovider geeft een tijdelijke fout, of je app slaat stap A op maar crasht voor stap B. Het gevaar is simpel: je probeert opnieuw en doet per ongeluk de actie twee keer.

Bij request-response API's is het gebruikelijke patroon dat de client een endpoint aanroept, wacht en als er geen duidelijke succesmelding komt, het opnieuw probeert. Om dat veilig te maken, moet de server herhaalde calls als dezelfde intentie behandelen.

Een praktische oplossing is een idempotentie-key: de client stuurt een unieke token zoals pay:invoice-583:attempt-1. De server slaat de uitkomst voor die sleutel op en geeft hetzelfde resultaat terug bij herhaalde pogingen. Dat voorkomt dubbele kosten, dubbele tickets of dubbele goedkeuringen.

Evenementgestuurde workflows hebben een ander soort duplicatierisico. Events worden vaak minstens één keer afgeleverd, wat betekent dat duplicaten kunnen verschijnen zelfs als alles werkt. Consumenten moeten deduplicatie doen: sla het event-ID (of een zakelijke sleutel zoals invoice_id + step) op en negeer herhalingen. Dit is een kernverschil: request-response focust op veilige herhaling van calls, events op veilige herhaling van berichten.

Een paar retryregels werken goed in beide modellen:

• Gebruik backoff (bijvoorbeeld 10s, 30s, 2m).
• Stel een maximaal aantal pogingen in.
• Scheid tijdelijke fouten (retry) van permanente fouten (snel falen).
• Routeer herhaalde fouten naar een “needs attention”-status.
• Log elke poging zodat je later kunt uitleggen wat er gebeurde.

Retries moeten expliciet in het proces zitten, niet verborgen gedrag. Zo maak je fouten zichtbaar en oplosbaar.

Audittrails: het proces verklaarbaar maken

Een audittrail is je "waarom"-bestand. Als iemand vraagt: “Waarom is deze onkost afgewezen?” moet je zonder gissen kunnen antwoorden, zelfs maanden later. Dit geldt voor zowel evenementgestuurde workflows als request-response API's, maar het werk ziet er anders uit.

Voor elk langdurig proces: leg de feiten vast waarmee je het verhaal kunt afspelen:

• Actor: wie deed het (gebruiker, service of systeemtimer)
• Tijd: wanneer het gebeurde (inclusief tijdzone)
• Input: wat op dat moment bekend was (bedrag, leverancier, beleidsdrempels, goedkeuringen)
• Output: welke beslissing of actie gebeurde (goedgekeurd, afgewezen, betaald, opnieuw geprobeerd)
• Regelversie: welke policy/logic-versie is gebruikt

Evenementgestuurde workflows maken auditen vaak makkelijker omdat elke stap natuurlijk een event produceert zoals “ManagerApproved” of “PaymentFailed.” Als je die events met payload en actor opslaat, krijg je een schone tijdlijn. De sleutel is dat events beschrijvend moeten zijn en ergens staan waar je per case kunt zoeken.

Request-response API's kunnen ook auditbaar zijn, maar het verhaal ligt vaak verspreid over services. De ene endpoint logt “approved”, een andere logt “payment requested” en een derde logt “retry succeeded”. Als elk een ander formaat gebruikt, wordt auditen detectivewerk.

Een simpele oplossing is een gedeelde “case ID” (ook correlatie-ID genoemd). Het is één identifier die je aan elk request, event en database-record voor die procesinstantie koppelt, bijvoorbeeld “EXP-2026-00173.” Daarmee kun je de hele reis volgen.

De juiste aanpak kiezen: sterktes en afwegingen

De beste keuze hangt ervan af of je meteen een antwoord nodig hebt, of dat het proces uren of dagen moet doorgaan.

Request-response werkt goed wanneer het werk kort is en de regels simpel. Een gebruiker verstuurt een formulier, de server valideert, slaat data op en geeft succes of fout terug. Het past ook bij eenduidige, enkelstapsacties zoals create, update of check permissions.

Het wordt pijnlijk wanneer een “enkele request” stilletjes veel stappen wordt: wachten op een goedkeuring, meerdere externe systemen aanroepen, timeouts afhandelen of vertakken op wat er vervolgens gebeurt. Je houdt ofwel een verbinding open (fragiel), of je duwt wachten en retries naar achtergrondjobs die lastig te begrijpen zijn.

Evenementgestuurde workflows excelleren wanneer het proces een verhaal over tijd is. Elke stap reageert op een nieuw event (approved, rejected, timer fired, payment failed) en beslist wat er daarna gebeurt. Dit maakt pauzeren, hervatten, opnieuw proberen en het bijhouden van een duidelijke reden eenvoudiger.

Er zijn echte afwegingen:

• Simpliciteit versus duurzaamheid: request-response is eenvoudiger om mee te beginnen, event-driven is beter voor lange vertragingen.
• Debugging-stijl: request-response volgt een rechte lijn, workflows vragen vaak tracing over stappen.
• Tooling en gewoontes: events vragen goede logging, correlatie-ID's en heldere statemodellen.
• Wijzigingsbeheer: workflows evolueren en vertakken; gebeurtenisgestuurde ontwerpen gaan vaak beter om met nieuwe paden als ze goed gemodelleerd zijn.

Een praktisch voorbeeld: een onkostennota die managergoedkeuring, dan financiële review en vervolgens betaling nodig heeft. Als betaling faalt, wil je retries zonder dubbel betalen. Dat is natuurlijk event-driven. Als het slechts “verstuur onkost” met snelle controles is, is request-response vaak voldoende.

Stappenplan: ontwerp een langdurig proces dat vertragingen overleeft

Langdurige bedrijfsprocessen falen op saaie manieren: een browsertab sluit, een server herstart, een goedkeuring duurt drie dagen of een payment provider time-out. Ontwerp voor die vertragingen vanaf het begin, ongeacht welk model je kiest.

Begin met het definiëren van een kleine set staten die je kunt opslaan en hervatten. Als je niet uit je database kunt aanwijzen wat de huidige status is, heb je geen werkelijk hervatbare workflow.

Een eenvoudig ontwerpproces

1. Stel grenzen: definieer de starttrigger, de eindconditie en enkele sleutelstaten (Pending approval, Approved, Rejected, Expired, Completed).
2. Geef events en beslissingen namen: schrijf op wat er in de tijd kan gebeuren (Submitted, Approved, Rejected, TimerFired, RetryScheduled). Gebruik werkwoordsvormen in verleden tijd voor event-namen.
3. Kies wachtpunten: identificeer waar het proces pauzeert voor een mens, een extern systeem of een deadline.
4. Voeg timer- en retryregels per stap toe: beslis wat er gebeurt als de tijd verstrijkt of een call faalt (backoff, max attempts, escaleer, stop proberen).
5. Definieer hoe het proces hervat: laad bij elk event of callback de opgeslagen status, verifieer dat die nog geldig is en ga dan naar de volgende status.

Bewaar voor hervatten minimaal de data die je nodig hebt om veilig door te gaan. Sla genoeg op om zonder gissen te kunnen herhalen:

• Procesinstantie-ID en huidige status
• Wie er daarna kan handelen (assignee/rol) en wat zij besloten
• Deadlines (due_at, remind_at) en escalatieniveau
• Retry-metadata (aantal pogingen, laatste fout, next_retry_at)
• Idempotency-key of "already done"-vlaggen voor bijwerkingen (bericht verzonden, kaart belast)

Als je kunt reconstrueren “waar we zijn” en “wat nu is toegestaan” uit opgeslagen data, stoppen vertragingen met beangstigen.

Veelgemaakte fouten en hoe ze te vermijden

Langdurige processen breken meestal pas als echte gebruikers verschijnen. Een goedkeuring duurt twee dagen, een retry vuurt op het verkeerde moment en je eindigt met een dubbele betaling of een ontbrekend auditspoor.

Veelgemaakte fouten:

• Een HTTP-request openhouden tijdens wachten op een menselijke goedkeuring. Het loopt vast, gebruikt serverresources en geeft de gebruiker een vals gevoel dat “er iets gebeurt.”
• Calls opnieuw proberen zonder idempotentie. Een netwerkstoring wordt een dubbele factuur, dubbele e-mail of herhaalde “Approved”-transitie.
• Processtatus alleen in geheugen houden. Een herstart wist het. Als status alleen in logs zit, kun je niet betrouwbaar verder.
• Een wazig auditspoor bouwen. Events hebben verschillende klokken en formaten, waardoor de tijdlijn tijdens een incident of compliance-review onbetrouwbaar wordt.
• Async en sync mixen zonder één bron van waarheid. Het ene systeem zegt “Paid”, een ander zegt “Pending” en niemand weet wat waar is.

Een simpel voorbeeld: een onkostennota wordt in chat goedgekeurd, een webhook komt te laat binnen en de payment-API wordt opnieuw geprobeerd. Zonder opgeslagen state en idempotentie kan de retry leiden tot dubbele betaling en onduidelijke administratie over waarom.

De meeste oplossingen komen neer op expliciet zijn:

• Persistente staatsovergangen (Requested, Approved, Rejected, Paid) met wie/waarom ze zijn veranderd.
• Idempotentie-keys voor elke externe bijwerking en de uitkomst opslaan.
• Scheid “accepteer de aanvraag” van “maak het werk af”: geef snel antwoord, en voltooi de workflow daarna op de achtergrond.
• Standaardiseer tijdstempels (UTC), voeg correlatie-ID's toe en registreer zowel het verzoek als de uitkomst.

Snelle checklist voordat je bouwt

Langdurig werk gaat minder over één perfecte call en meer over correct blijven na vertragingen, mensen en fouten.

Schrijf op wat “veilig om door te gaan” betekent voor jouw proces. Als de app halverwege herstart, moet je kunnen verdergaan vanaf de laatst bekende stap zonder te gokken.

Een praktische checklist:

• Definieer hoe het proces hervat na een crash of deploy. Welke status is opgeslagen en wat draait daarna?
• Geef elke instantie een unieke proceskey (zoals ExpenseRequest-10482) en een duidelijk statusmodel (Submitted, Waiting for Manager, Approved, Paid, Failed).
• Behandel goedkeuringen als records, niet alleen uitkomsten: wie goedkeurde of weigerde, wanneer en de reden of opmerking.
• Breng wachtrregels in kaart: reminders, deadlines, escalaties, expiraties. Benoem een eigenaar voor elke timer (manager, finance, system).
• Plan foutafhandeling: retries moeten beperkt en veilig zijn, en er moet een “needs review”-stop zijn waar een persoon data kan herstellen of een herpoging kan goedkeuren.

Een sanitytest: stel je voor dat een payment provider time-out gaat nadat je de kaart al hebt belast. Je ontwerp moet dubbele belading voorkomen en toch het proces kunnen afronden.

Voorbeeld: onkostengoedkeuring met deadline en betaalretry

Scenario: een medewerker dient een taxi bon van $120 in voor vergoeding. Het moet binnen 48 uur door de manager worden goedgekeurd. Als goedgekeurd, betaalt het systeem uit aan de medewerker. Als betaling faalt, probeert het veilig opnieuw en laat een duidelijk verslag achter.

Request-response walkthrough

Bij request-response API's gedraagt de app zich vaak als een gesprek dat steeds moet bijhouden.

De medewerker drukt op Submit. De server maakt een reimbursements-record met status “Pending approval” en geeft een ID terug. De manager krijgt een notificatie, maar de medewerker-app moet meestal pollen om te zien of er iets veranderd is, bijvoorbeeld: “GET reimbursement status by ID.”

Om de 48-uur regel af te dwingen, draai je ofwel een geplande taak die overdue requests scant, of je slaat een deadline-timestamp op en controleert die tijdens polls. Als de job vertraagd is zien gebruikers mogelijk verouderde status.

Wanneer de manager goedkeurt, zet de server de status op “Approved” en roept de payment provider aan. Als Stripe een tijdelijke fout teruggeeft, moet de server beslissen of hij nu opnieuw probeert, later opnieuw probeert of faalt. Zonder zorgvuldige idempotentie-keys kan een retry een dubbele uitbetaling veroorzaken.

Event-driven walkthrough

In een event-driven model is elke verandering een vastgelegd feit.

De medewerker dient in en dat produceert een “ExpenseSubmitted” event. Een workflow start en wacht op óf “ManagerApproved” óf een “DeadlineReached” timer event na 48 uur. Als de timer eerst afloopt, registreert de workflow een “AutoRejected” uitkomst en waarom.

Bij goedkeuring registreert de workflow “PayoutRequested” en probeert de betaling. Als Stripe time-outt, registreert het “PayoutFailed” met een foutcode, plant een retry (bijv. over 15 minuten) en registreert alleen “PayoutSucceeded” eenmaal met behulp van een idempotency-key.

Wat de gebruiker ziet blijft simpel:

• Pending approval (48 uur resterend)
• Goedgekeurd, uitbetaling gestart
• Betaalretry gepland
• Betaald

De audittrail leest als een tijdlijn: submitted, approved, deadline gecontroleerd, payout geprobeerd, gefaald, opnieuw geprobeerd, betaald.

Volgende stappen: zet het model om in een werkende app

Kies één echt proces en bouw het end-to-end voordat je generaliseert. Onkostgoedkeuring, onboarding en refund-afhandeling zijn goede starters omdat ze menselijke stappen, wachten en foutpaden bevatten. Houd het doel klein: één happy path en de twee meest voorkomende uitzonderingen.

Schrijf het proces als staten en events, niet als schermen. Bijvoorbeeld: “Submitted” -> “ManagerApproved” -> “PaymentRequested” -> “Paid,” met takken zoals “ApprovalRejected” of “PaymentFailed.” Als je de wachtpunten en bijwerkingen helder ziet, wordt de keuze tussen evenementgestuurde workflows en request-response API's praktisch.

Bepaal waar processtatus woont. Een database kan genoeg zijn als de flow eenvoudig is en je updates op één plek afdwingt. Een workflow-engine helpt wanneer je timers, retries en vertakkingen nodig hebt, omdat die bijhoudt wat er daarna moet gebeuren.

Voeg auditvelden vanaf dag één toe. Sla op wie wat deed, wanneer het gebeurde en waarom (opmerking of redencode). Als iemand vraagt “Waarom is deze betaling opnieuw geprobeerd?” wil je een duidelijk antwoord zonder in logs te graven.

Als je dit soort workflow in een no-code platform bouwt, is AppMaster (appmaster.io) een optie waarbij je data in PostgreSQL kunt modelleren en proceslogica visueel kunt bouwen, wat het makkelijker maakt om goedkeuringen en auditsporen consistent te houden in web- en mobiele apps.