Event-driven architectuur (EDA) is een manier om software te bouwen waarbij onderdelen van een systeem met elkaar communiceren door aan te kondigen dat er iets is gebeurd, in plaats van elkaar rechtstreeks aan te roepen. Eén component publiceert een event, zoals “factuur betaald” of “contract ondertekend”. Elk ander component dat daarin geïnteresseerd is, reageert erop. Geen van beide kanten hoeft te weten dat de ander bestaat.

Voor een SaaS-bedrijf is dit veel meer dan een engineeringkwestie. Hetzelfde idee zit achter nette overdrachten van CRM naar finance, betrouwbare automatisering en AI-agents die op actuele data handelen. Deze gids legt uit hoe EDA werkt, hoe een event bus verschilt van een queue, hoe u de veelvoorkomende fouten voorkomt en waar EDA wel en niet thuishoort.

Kort samengevat

Inhoudsopgave

Wat event-driven architectuur is

De architectuurrichtlijnen van Microsoft beschrijven de stijl als event producers die een stroom van events genereren, event consumers die ernaar luisteren en event channels die events van de een naar de ander brengen. Dat model van drie delen is het hele idee. Al het andere is detail over hoe betrouwbaar en hoe snel het kanaal werkt.

Het tegenovergestelde is request/response. In een request/response-ontwerp roept uw billingservice uw CRM aan en wacht op een antwoord. Als het CRM traag is of uitvalt, zit billing vast. In een event-driven ontwerp publiceert billing “betaling ontvangen” en gaat verder. Het CRM, het omzetrapport en het customer success-dashboard pakken het event elk op wanneer ze eraan toe zijn.

Hieruit volgen twee eigenschappen:

Wat als event geldt

Een event is een feitelijke mededeling in de verleden tijd. Red Hat beschrijft het als een onveranderlijke vastlegging dat er iets is gebeurd, vaak met een tijdstempel die de volgorde ten opzichte van het systeem dat het voortbracht bewaart. Een event past u achteraf niet aan. Als er iets verandert, legt een nieuw event de wijziging vast.

AWS merkt op dat events een statuswijziging of een update kunnen zijn en dat ze de status kunnen meedragen of identifiers kunnen zijn. Twee voorbeelden:

Stijl Voorbeeld Wat de consumer ontvangt
Event dat de status meedraagt Abonnement geüpgraded, met plan, prijs, ingangsdatum en account-ID Alles wat nodig is om te handelen zonder tweede opzoeking
Event als identifier Bestelling verzonden, alleen met de order-ID Een signaal. De consumer haalt de details op bij het bronsysteem

De eerste variant is handig, maar koppelt consumers aan de vorm van het event. De tweede houdt events klein, maar stuurt consumers terug naar het bronsysteem, wat de vraag oproept welk systeem leidend is. Daar komen we hieronder op terug, want daar worstelen de meeste SaaS-operationsstacks mee.

Een command is geen event. “Verstuur de factuur” is een instructie aan een specifieke ontvanger. “Factuur verstuurd” is een feit waar iedereen op kan reageren. Beide door elkaar halen is een veelgemaakte ontwerpfout en bouwt ongemerkt de sterke koppeling weer op die u juist wilde wegnemen.

Hoe een event-driven systeem werkt, stap voor stap

De documentatie van Google Cloud beschrijft de stroom: producers genereren events, een router of broker neemt ze op en filtert ze, en verspreidt ze vervolgens naar consumers op basis van abonnementen of triggers. In de praktijk:

  1. Er gebeurt iets. Een deal gaat in de CRM naar “Closed Won”.
  2. De producer publiceert een event. Het benoemt het feit en het record waar het over gaat.
  3. De broker routeert het. Hij filtert het event en levert het af bij elke abonnee.
  4. Consumers reageren onafhankelijk van elkaar. Finance maakt een conceptfactuur aan. Customer Success opent een onboardingplan. Een provisioningproces bereidt de toegang voor.
  5. Elke consumer bevestigt de ontvangst. De broker weet dat het event is afgehandeld en kan het opnieuw proberen als dat niet gelukt is.

IBM beschrijft hetzelfde patroon als publicatie, vastlegging, verwerking en opslag van events en wijst erop dat de waarde van een event in de loop van de tijd kan veranderen. Op een “new lead”-event wilt u binnen enkele minuten reageren. Een jaar later is het vooral nuttig voor analyse.

Event-driven architectuur en microservices

Mensen zien deze twee vaak als hetzelfde. Dat zijn ze niet. Microservices beschrijven hoe u een applicatie opsplitst in kleine, onafhankelijk uitgerolde services. EDA beschrijft hoe die services met elkaar communiceren. U kunt microservices hebben die elkaar synchroon aanroepen, en u kunt een monoliet hebben die intern events publiceert.

Beide werken goed samen. Volgens de richtlijnen van Google kunnen microservices asynchroon op events reageren en hoeven ze alleen het eventformaat te kennen, niet elkaars bedrijfslogica. Dat gedeelde formaat is het contract. Alles erachter kan veranderen.

De documentatie van Microsoft beschrijft het typische patroon als microservices die een event publiceren wanneer er iets noemenswaardigs gebeurt, terwijl andere microservices zich erop abonneren.

Event bus versus queue versus stream

Deze drie begrippen veroorzaken de meeste verwarring, en uw keuze bepaalt hoe uw systeem zich gedraagt.

Event bus (publish/subscribe). Een event bus is een mechanisme waarbij publishers events aankondigen en abonnees ze ontvangen. Microsoft legt uit dat dit kan worden geïmplementeerd op messaginginfrastructuur zoals een queue of service bus die asynchrone publish/subscribe ondersteunt. Een queue kan dus een van de bouwstenen van een bus zijn. De bus is de bedoeling. De queue is één manier om die te realiseren.

Queue. Een queue bewaart berichten totdat een worker ze oppakt. Elk bericht wordt normaal gesproken door één consumer afgehandeld. Queues zijn het juiste hulpmiddel om werk over workers te verdelen en pieken op te vangen. De integratierichtlijnen van Azure noemen berichten in de wachtrij zetten wanneer een back-end niet beschikbaar is als één reden om een broker te gebruiken.

Event stream. Azure maakt onderscheid tussen publish/subscribe en streaming. Bij publish/subscribe wordt een ontvangen event niet in een duurzaam log bewaard, zodat nieuwe abonnees eerdere events niet zien. Bij streaming worden events weggeschreven naar een log dat duurzaam is en binnen een partitie strikt geordend, en clients lezen uit het log, kunnen op elk moment aansluiten en events opnieuw afspelen.

Queue Publish/subscribe-bus Event stream
Aflevering Eén consumer per bericht Elke abonnee Elke lezer, vanaf elk punt
Eerdere events Verwijderd na verwerking Niet beschikbaar voor nieuwe abonnees Bewaard en opnieuw af te spelen
Typisch gebruik Werkverdeling, buffering Meerdere systemen op de hoogte stellen Historie, analyse, status opnieuw opbouwen

Een praktische vuistregel: als meerdere systemen op hetzelfde feit moeten reageren, gebruikt u publish/subscribe. Als één worker een taak moet uitvoeren, gebruikt u een queue. Als u historie nodig hebt of een downstreamsysteem opnieuw moet kunnen opbouwen, gebruikt u een stream. Red Hat voegt toe dat er geen oplossing is die voor alles past, dus kies de technologie op basis van het type event.

Is Kafka een event-driven architectuur?

Nee. Kafka is een technologie waarmee u er een kunt bouwen. De documentatie van Apache Kafka beschrijft het als een platform voor event streaming: events in realtime vastleggen, duurzaam opslaan, verwerken en doorsturen naar andere systemen. Daarmee is het een event stream uit de tabel hierboven.

Een architectuur is een geheel van ontwerpbeslissingen: wat de events zijn, wie ze beheert, hoe consumers van elkaar geïsoleerd zijn en wat er bij een storing gebeurt. U kunt die beslissingen nemen en uitvoeren op een beheerde cloud-bus, een queueservice of Kafka. U kunt ook Kafka draaien en toch een sterk gekoppeld systeem houden als elke service afhankelijk is van de interne events van een andere service. Kies de tool nadat u hebt bepaald wat de events zijn en welk volume u daadwerkelijk verwacht.

Event-driven integratie en automatisering

Hier wordt EDA relevant voor operationele leiders en niet alleen voor engineers.

Integratie

De meeste SaaS-bedrijven koppelen hun CRM-, facturatie-, support- en productdata met point-to-point-synchronisaties. Elke nieuwe tool voegt een extra koppeling toe die onderhouden moet worden. Azure adviseert asynchrone communicatie via een message broker in plaats van directe synchrone aanroepen, om vier redenen die het zelf noemt: applicaties ontkoppelen, naar meerdere consumers uitzenden, langlopende workflows betrouwbaar volgen en berichten in de wachtrij zetten wanneer een back-end niet beschikbaar is.

Het voordeel wordt zichtbaar wanneer u een systeem toevoegt. Met een publish/subscribe-service kunnen nieuwe abonnees worden toegevoegd zonder de afzender aan te passen. Een nieuwe analysetool toevoegen vraagt dus geen wijziging in uw CRM.

Automatisering

Event-driven automatisering betekent dat een bedrijfsproces start omdat er iets gebeurde, en niet omdat iemand op een knop klikte of een nachtelijke job draaide. De flowgids van ServiceNow geeft een praktische methode: bepaal de trigger, plan de logica, kies de acties en bepaal welke logica herbruikbaar is. Ook wordt aangeraden flows gefocust te houden en één werkwoord per actie te gebruiken.

Wanneer een proces meerdere services omvat, merkt Microsoft op dat event-driven systemen vaak choreografie- en saga-orkestratiepatronen gebruiken om de stroom te coördineren. Bij choreografie reageert elke service op events en zendt zelf nieuwe uit. Bij orkestratie vertelt een coördinator elke stap wat die moet doen en volgt hij het hele proces. Voor een eerste project is een georkestreerde flow meestal beter leesbaar en controleerbaar.

Een eenvoudig SaaS-voorbeeld:

Best practices en veelvoorkomende uitdagingen

Azure noemt de belangrijkste uitdagingen: eventual consistency, asynchrone foutafhandeling, dataverlies, observeerbaarheid en testen, te veel of te sterk gebundelde events, en schema-evolutie. Voor elk ervan bestaat een passende werkwijze.

  1. Houd rekening met eventual consistency. Systemen zullen elkaar kortstondig tegenspreken. Bepaal per feit welk systeem leidend is en laat de andere systemen dat volgen.
  2. Voeg een speciale foutafhandelaar toe. Mislukte events hebben een plek nodig waar ze naartoe gaan en iemand die ernaar kijkt.
  3. Bewaar events totdat de ontvangst is bevestigd. Dit beschermt tegen dataverlies wanneer een afnemer niet beschikbaar is.
  4. Gebruik correlatie-ID's. Eén ID dat door elke stap meegaat, laat u één klantactie over systemen heen volgen.
  5. Zoek een evenwicht in de granulariteit van events. Eén event per gewijzigd veld zorgt voor ruis. Eén gigantisch event voor alles brengt de koppeling terug.
  6. Geef schema's vroeg een versie. Eventformaten zullen veranderen. Bepaal hoe, voordat u twintig afnemers heeft.

Hieraan voegen wij drie operationele gewoonten toe: geef events een naam in de verleden tijd, geef elk eventtype één eigenaar en leg vast welke afnemers ervan afhankelijk zijn.

Waar event-driven ontwerp niet thuishoort

EDA is niet het antwoord op elk probleem. Wees expliciet over de grenzen voordat u zich verbindt:

Dezelfde logica geldt voor AI. Een AI-assistent die uw systemen leest en daarin handelt, is zowel afnemer als producent van events. Als hij inconsistente data leest of handelt zonder bevoegdheidsgrens, maakt u sneller fouten.

Waar dit samenkomt met AI-agents en compliance

AI-agents die data ophalen (vragen, rapporteren, opzoeken) en data wegschrijven (een record bijwerken, een proces starten, toegang verlenen) gedragen zich als deelnemers aan een event-driven systeem. Ze hebben een betrouwbare bron nodig om te lezen, een duidelijke set acties die ze mogen uitvoeren, goedkeuring voor gevoelige stappen en een vastlegging van wat ze hebben gedaan. Een eventlog is daarvoor een logische plek.

Operator die een eventlog van een AI-agent bekijkt

Voor Europese bedrijven hebben de AVG (GDPR), NIS2 en de EU AI Act allemaal invloed op hoe dergelijke systemen worden ontworpen. In algemene termen gaat het om welke persoonsgegevens door events stromen, hoe beveiliging en incidentafhandeling zijn georganiseerd, en hoe AI-systemen worden bestuurd en gedocumenteerd. Behandel ze vanaf het begin als ontwerpinput en vraag juridisch advies aan een jurist over hoe ze op uw specifieke situatie van toepassing zijn. Geen enkele architectuurkeuze maakt een systeem op zichzelf compliant.

Onze visie

De meeste SaaS-bedrijven waarmee wij praten hebben geen eventprobleem. Ze hebben een eigenaarschapsprobleem. Meerdere teams gebruiken AI, meerdere tools bevatten een eigen versie van de klant en niemand is verantwoordelijk voor welke versie de juiste is.

Daarom werken wij in een vaste volgorde. Eerst de data foundation: de CRM- en financiële data als de afgesproken bron van waarheid. Dan de AI-laag, die die data koppelt aan de assistent die uw team al gebruikt. Dan afdelingsagents voor Finance, Sales en Customer Success. Events zijn nuttig in alle drie de lagen, maar ze helpen pas zodra de feiten die ze dragen zijn afgestemd.

Ook voeren wij steeds één proces tegelijk in, te beginnen met het duurste. Een verlengingsproces of een overdracht van factuur tot betaling is een beter eerste event-driven project dan een herbouw van het hele bedrijf. U ziet het resultaat, uw mensen leren het patroon en het volgende proces wordt goedkoper.

Omdat wij naast het ontwerpen van systemen ook de operatie draaien, geven wij om de saaie onderdelen: rechten, goedkeuringen, audit trails en een overdracht waarbij u de code, documentatie en infrastructuur in eigendom krijgt.

Claus Nielsen

Aan de slag in uw eigen bedrijf

U hoeft niet eerst een broker te kiezen. Begin met deze vragen:

  1. Welk proces kost u het meeste aan handwerk, vertraging of fouten?
  2. Wat zijn de twee of drie events die het starten (bijvoorbeeld deal gesloten, factuur achterstallig, verlenging nadert)?
  3. Welk systeem is de bron van waarheid voor de data in die events?
  4. Wie is eigenaar van elke eventdefinitie?
  5. Welke stappen vereisen goedkeuring door een mens?

Als u de derde vraag niet kunt beantwoorden, komt eerst de data foundation. Als u dat wel kunt, laat een kleine pilot op één proces zien of een event-driven aanpak loont.

Hoe wij kunnen helpen

Als uw team AI gebruikt maar niemand er eigenaar van is, helpen wij u te bepalen waar het loont en het in de juiste volgorde te bouwen. Onze AI Readiness Assessment is beschikbaar vanaf €4,500 en kijkt naar uw data, systemen en processen voordat er iets wordt gebouwd. Wilt u doorlopende aansturing, dan start de Fractional Chief AI Officer-retainer vanaf €1,500 per maand.

Builds worden geprijsd op 30% van een gemeten en bewezen besparing in het eerste jaar, of tegen een vaste prijs die vóór de start van het werk is afgesproken. U kunt ook een gratis kennismakingsgesprek van 30 minuten boeken via onze site. Onze AI-agents voor Finance, Sales en Customer Success laten zien hoe de afdelingslaag eruitziet zodra de basis er ligt.

FAQ

Wat is event-driven architectuur in eenvoudige woorden?

Het is een ontwerp waarbij softwarecomponenten aankondigen dat er iets is gebeurd, en andere componenten daarop reageren. De afzender weet niet wie er luistert. Zo kunt u systemen toevoegen of wijzigen zonder de systemen die de events produceren te herschrijven.

Wat is het verschil tussen een eventbus en een berichtenwachtrij?

Een wachtrij levert elk bericht meestal aan één worker. Een eventbus levert elk event aan alle abonnees. Een bus kan op wachtrij-infrastructuur worden gebouwd, dus het verschil zit in de bedoeling en het afleverpatroon, niet altijd in het product.

Is event-driven architectuur hetzelfde als microservices?

Nee. Bij microservices gaat het erom hoe een applicatie in services wordt opgesplitst. Bij event-driven architectuur gaat het erom hoe onderdelen met elkaar communiceren. Ze worden vaak samen gebruikt, maar elk kan zonder de ander bestaan.

Wanneer moet een SaaS-bedrijf event-driven automatisering inzetten?

Zet het in wanneer een bedrijfsproces moet starten vanuit een feit, zoals een gesloten deal of een naderende verlenging, en meerdere teams of systemen daarop moeten reageren. Begin met één kostbaar proces en zorg dat er eerst overeenstemming is over de brondata.

Bronnen