REST of event-driven integratie? 3 beslisvragen voor het juiste integratiepatroon
Veel teams maken de keuze tussen REST en event-driven integratie te vroeg en op de verkeerde gronden. Soms omdat een organisatie al veel API’s heeft en dus automatisch naar REST grijpt. Soms omdat event-driven “moderner” klinkt en daarom vrijwel automatisch de voorkeursrichting wordt. Beide reflexen zijn te simpel.
De juiste keuze hangt niet af van hype of voorkeur, maar van procesgedrag. Heeft een consumer direct antwoord nodig? Moeten meerdere systemen reageren op hetzelfde feit? En mag verwerking asynchroon verlopen zonder dat de business of gebruikerservaring daaronder lijdt?
Juist die vragen bepalen hoe sterk systemen runtime aan elkaar gekoppeld raken, hoe fouten zich gedragen, hoeveel operationele discipline nodig is en hoe schaalbaar het landschap op termijn blijft. Hieronder een praktisch keuze-kader dat helpt om die afweging expliciet en verdedigbaar te maken.
De beslisboom hierboven geeft het snelle overzicht. In de rest van dit artikel werken we de drie vragen uit, inclusief de nuance die in veel enterprise-landschappen het verschil maakt: de beste keuze is vaak niet óf REST óf event-driven, maar een bewuste combinatie van beide.
Vraag 1 — Is directe respons nodig?
De eerste en vaak belangrijkste vraag is of de consumer direct een antwoord nodig heeft om verder te kunnen. Als een gebruiker in een scherm werkt, een proces meteen een bevestiging nodig heeft of een systeem geen volgende stap kan zetten zonder actuele respons, dan wijst dat meestal richting REST.
Dat patroon is logisch voor situaties zoals:
- validatie van invoer tijdens een transactie;
- opvragen van actuele status of referentiedata;
- een front-end die direct product- of klantinformatie moet tonen;
- een command-actie waarvan de uitkomst meteen duidelijk moet zijn.
REST past hier goed omdat het model eenvoudig en expliciet is. Een consumer stelt een vraag, een service geeft antwoord, en statuscodes en foutmeldingen maken het gedrag direct inzichtelijk. Dat helpt zowel functioneel als operationeel: fouten worden meteen zichtbaar en zijn meestal eenvoudiger te reproduceren dan in asynchrone ketens.
Maar hier zit ook een bekende valkuil. Veel organisaties maken alles synchroon “voor het gemak”, terwijl niet elk proces directe feedback nodig heeft. Daardoor ontstaan ketens waarin service A wacht op B, B op C en C op D. Dat werkt zolang alles gezond is, maar zodra één schakel traag wordt of uitvalt, voelt de hele keten dat onmiddellijk.
De vraag is dus niet alleen óf directe respons gewenst is, maar óf die echt een harde eis is. Als het antwoord daarop ja is, is REST vaak de juiste keuze. Als het antwoord eigenlijk nee is, dan wordt synchronie al snel een bron van onnodige coupling.
Vraag 2 — Moeten meerdere systemen reageren op hetzelfde feit?
De tweede beslisvraag gaat over fan-out. Als één verandering of gebeurtenis relevant is voor meerdere afnemers, dan wordt point-to-point integratie snel onhandig. Een producer moet dan steeds meer consumers kennen, aanroepen en in leven houden, terwijl de koppelingen juist zouden moeten afnemen naarmate een landschap groeit.
Daar is event-driven integratie meestal sterker. In plaats van meerdere systemen rechtstreeks aan te roepen, publiceert een producer één gebeurtenis, waarna meerdere consumers daar onafhankelijk op kunnen reageren.
Denk aan gebeurtenissen zoals:
- een order is geplaatst;
- een klantprofiel is gewijzigd;
- een campagne is geactiveerd;
- een document is goedgekeurd.
Zo’n feit kan relevant zijn voor meerdere afnemers tegelijk: notificaties, analytics, fulfillment, CRM-verrijking of downstream synchronisatie. Met een broker of event bus hoeft de producer die consumers niet allemaal expliciet te kennen. Dat verlaagt de directe afhankelijkheden en maakt uitbreiding eenvoudiger.
Dat voordeel krijg je niet gratis. Event-driven werkt alleen goed als de basisdiscipline op orde is:
- consumers moeten idempotent zijn;
- delivery failures moeten goed afgehandeld worden;
- events moeten stabiel en versioneerbaar zijn;
- observability moet over systemen heen werken;
- ownership van brondata moet scherp blijven.
Zonder die randvoorwaarden wordt event-driven geen schaalbaar patroon maar een ondoorzichtig landschap waarin veel gebeurt, maar niemand precies weet waar een effect vandaan komt of waarom iets twee keer verwerkt werd.
De praktische vuistregel is: als meerdere systemen moeten reageren op hetzelfde feit, dan verdient event-driven serieuze voorkeur. Niet omdat het modieus is, maar omdat het patroon past bij wat er werkelijk gebeurt: één feit, meerdere gevolgen.
Vraag 3 — Is asynchrone verwerking acceptabel?
De derde vraag gaat over tijd. Niet elk proces hoeft onmiddellijk afgerond te zijn. Veel handelingen mogen best seconden of zelfs minuten later downstream verwerkt worden, zolang dat maar bewust ontworpen is en voor de business acceptabel blijft.
Juist daar ligt de kracht van event-driven integratie. Als een aanroeper niet hoeft te wachten op alle vervolgstappen, dan wordt de keten robuuster. Tijdelijke verstoringen downstream blokkeren de producer niet meteen. Buffers, retries en herverwerking kunnen hun werk doen zonder dat de initiële actie direct stukloopt.
Dat maakt een groot verschil in productie. Een synchrone keten is vaak zo sterk als de zwakste schakel: valt één service weg, dan voelt de hele requestketen dat. In een asynchroon model kan de producer vaak gewoon doorgaan, terwijl consumers later inhalen of retries uitvoeren.
Maar asynchrone verwerking is alleen acceptabel als:
- eventual consistency functioneel verdedigbaar is;
- gebruikers niet direct een definitieve uitkomst hoeven te zien;
- downstream acties later mogen plaatsvinden;
- het proces duidelijk maakt wat “geaccepteerd” betekent versus “volledig verwerkt”.
Zodra een gebruiker of proces wél onmiddellijke zekerheid nodig heeft, wordt asynchronie eerder verwarrend dan behulpzaam. Dan krijg je ingewikkelde workarounds: polling, statusschermen, pseudo-synchrone eventpaden of onduidelijke businessstatussen.
De essentie van deze derde vraag is daarom simpel: als tijdsontkoppeling acceptabel is, vergroot dat de ruimte voor event-driven ontwerp. Als dat niet acceptabel is, kom je al snel terug bij een synchrone aanpak zoals REST.
Nuance: in de praktijk vaak een combinatie
De belangrijkste ontwerpboodschap is dat volwassen enterprise-landschappen zelden volledig REST-first of volledig event-first zijn. In de praktijk werkt een combinatie meestal het best.
Een typisch patroon is:
- REST voor directe command-paden en interactieve processen;
- event-driven voor verspreiding van domeingebeurtenissen naar downstream systemen.
Neem bijvoorbeeld orderverwerking. Een front-end of orderservice kan synchroon via REST bevestigen dat een order ontvangen en geaccepteerd is. Daarna kan diezelfde service asynchroon een event publiceren, waarop fulfillment, analytics, notificaties en facturatie reageren. De gebruiker krijgt direct feedback, terwijl het landschap downstream losser gekoppeld blijft.
Dat is vaak architectonisch veel gezonder dan proberen alles synchroon of juist alles asynchroon te maken. De vraag is dus niet welk patroon “wint”, maar welk patroon het juiste gedrag ondersteunt op het juiste punt in de keten.
De beste keuze is meestal:
- synchroon waar directe zekerheid nodig is;
- asynchroon waar ontkoppeling, schaal of meerdere afnemers belangrijker zijn.
Samengevat: de drie beslisvragen
Als je moet kiezen tussen REST en event-driven integratie, begin dan niet bij technologie of voorkeur. Begin bij drie vragen:
- Heeft de consumer directe respons nodig?
- Moeten meerdere systemen reageren op hetzelfde feit?
- Is asynchrone verwerking acceptabel?
Met alleen die drie vragen wordt al veel duidelijker welk patroon architectonisch logisch is. Ze helpen om losse meningen te vervangen door expliciete ontwerpafwegingen — precies wat nodig is in enterprise-omgevingen waar systemen, teams en belangen samenkomen.
Bij Data Conductors gebruiken we dit soort keuze-kaders om integraties niet alleen werkend, maar ook beheersbaar te ontwerpen. Want de goedkoopste koppeling is zelden de koppeling die op termijn het meest wendbaar blijft.