Event sourcing is een datamodelleringstechniek die veranderingen in een systeem vastlegt als een opeenvolging van discrete gebeurtenissen, in plaats van alleen de huidige toestand op te slaan. Het is niet nieuw, maar het wordt steeds gebruikelijker omdat moderne systemen steeds meer event-driven werken.

Dit artikel schetst de basisprincipes van event sourcing, use cases, belangrijke implementatie-uitdagingen en praktische manieren om het te integreren zonder je data-architectuur te veel uit te breiden.

Stel dat je werkt in data engineering, analytics of architectuur. Dit is een concept dat het waard is om te begrijpen, vooral als je werk afhankelijk is van geschiedenis, traceerbaarheid of een duidelijk beeld van hoe processen zich ontvouwen.

Wat is event sourcing?

Event sourcing betekent het opslaan van elke betekenisvolle verandering als een discrete gebeurtenis in plaats van alleen de huidige toestand van het object.

Je slaat niet alleen de huidige status van een bestelling op. In plaats daarvan sla je de volledige reeks acties op die ertoe hebben geleid: “Item toegevoegd aan winkelwagentje” → “Betaling voltooid” → “Bestelling verzonden”.

Elk evenement is:

• Een historisch feit
  
• Gebonden aan een specifieke tijd
  
• Onveranderlijk (je verandert het nooit als het eenmaal geschreven is)
  

Door de gebeurtenissen opnieuw af te spelen, kun je de huidige toestand reconstrueren, of elke toestand op elk willekeurig moment in de tijd.

Denk Boekhouden

Een handige analogie: event sourcing is als dubbel boekhouden.

In de boekhouding zeg je niet zomaar: “We hebben op dit moment €5.000 op de bank staan.”
Je noteert elke journaalpost die je zover heeft gebracht: een verkoop, een betaling, een belastingaanpassing. Het grootboek laat zien hoe je tot het saldo van vandaag bent gekomen.

Event sourcing werkt op dezelfde manier: events zijn de journaalposten van je datamodel. De eindstatus is nuttig. Maar de weg ernaartoe? Dat is waar het echte inzicht zit.

Of, als boekhouden niet klikt voor jou:

Stel je een videospel voor dat elke beweging die je maakt registreert.

Je kunt de replay bekijken, pauzeren, terugspoelen en begrijpen hoe je hebt gewonnen of verloren.

Event sourcing werkt op dezelfde manier: je datasysteem bewaart elke beweging (gebeurtenis), niet alleen de eindscore.

Wat zijn de voordelen van event sourcing?

1. Unificeren van verschillen tussen bronsystemen

In een typisch datawarehouse stromen gegevens binnen vanuit meerdere bronsystemen, elk met hun eigen structuur, naamgevingsconventies en wijzigingsregistratie. Sommige systemen zijn van nature event-driven. Andere niet.

• Vaak event-driven: webtracking, mobiele apps, logging pipelines, e-commerce platforms, moderne microservices
  
• Vaak gebaseerd op de staat: CRM-systemen, ERP, financiële software, HR-tools
  

Door event sourcing op magazijnniveau toe te passen, creëer je een uniform model voor het weergeven van veranderingen: alles wordt uitgedrukt als een gebeurtenis met tijdstempel. Dit geeft je een consistente basis, ongeacht hoe het bronsysteem werkt.

Het vereenvoudigt de integratie, verbetert de vergelijkbaarheid en vermindert de behoefte aan aangepaste logica per systeem in uw downstream modellen.

2. Robuustheid door onveranderlijkheid

In deze event-source modellen zijn gebeurtenissen onveranderlijk: eenmaal geschreven, worden ze nooit bijgewerkt of verwijderd. Dit principe zorgt voor duidelijkheid en vertrouwen: wat gebeurd is, wordt opgeslagen zoals het gebeurd is, zonder stille correcties of verborgen overschrijvingen.

Dit verbetert de traceerbaarheid en controleerbaarheid en vereenvoudigt je dataverwerkingspijplijnen. Je transformatielogica wordt voorspelbaarder en stabieler na verloop van tijd, omdat de gegevens niet achteraf veranderen. Je hoeft je niet constant bezig te houden met late wijzigingen of correcties met terugwerkende kracht. In plaats daarvan verwerk je nieuwe gebeurtenissen op het moment dat ze binnenkomen.

In grootschalige gegevenssystemen is die stabiliteit goud waard. Het vermindert de operationele belasting, het risico op inconsistente uitvoer en de behoefte aan backfilled jobs of logische workarounds. Traditionele datapijplijnen hebben vaak moeite met late updates of correcties. In een onveranderlijk event model voeg je gewoon nieuwe events toe in plaats van de geschiedenis te herschrijven.

3. Klaar voor de toekomst – Afstemmen op een gebeurtenisgestuurde wereld

Veel moderne systemen, zoals webapplicaties, mobiele platforms en microservices, zijn inherent event-driven. Ze zenden van nature gebeurtenissen uit: gebruikersacties, systeemtriggers, API-aanroepen.

Door een event-based model te gebruiken in je datawarehouse, hoef je geen wijzigingen uit statustabellen achteraf in te passen of fragiele logica te bouwen om te raden wat er veranderd is. In plaats daarvan weerspiegelt je gegevensstructuur het gedrag van het bronsysteem.

Deze afstemming maakt uw architectuur eenvoudiger te onderhouden, vooral als systemen evolueren of worden vervangen. Je bent niet gebonden aan een specifieke versie van een CRM of ERP; je werkt met onbewerkte, tijdgestampte feiten die bestand zijn tegen schemaverschuivingen of proceswijzigingen.

Wanneer moet ik event sourcing gebruiken?

Event sourcing werkt het beste wanneer:

• Je geeft om geschiedenis, context en volgorde
  
• Je hebt traceerbaarheid nodig (bijv. audits, naleving van wettelijke voorschriften)
  
• Je wilt gebruikersgedrag, processtromen of conversiepaden begrijpen
  
• Je bronnen zijn al event-driven (of worden dat)
  

Dat gezegd hebbende, het hoeft niet alles of niets te zijn. Je kunt event logs waar nodig combineren met langzaam veranderende dimensies (SCD) of statustabellen.

Een praktisch voorbeeld van event-sourcing

In een van onze recente projecten hebben we event sourcing toegepast, ook al waren de meeste bronsystemen traditionele state-based platforms, die niet inherent event-driven waren.

Toch was het logisch. Waarom?

• De gegevensconsumenten (analisten, belanghebbenden) waren vooral geïnteresseerd in wat er gebeurde, niet alleen in de eindtoestand
  
• Er was een sterke behoefte aan controleerbaarheid en transparantie, zowel intern als extern
  
• En we wilden een toekomstbestendige fundering bouwen die zich kan aanpassen als bronsystemen evolueren
  

Door te ontwerpen rond een centraal gebeurtenissenlogboek creëerden we een duidelijk, consistent model van processtappen, ook al legden de oorspronkelijke systemen gebeurtenissen niet expliciet vast. Het resultaat was eenvoudiger om mee te werken, beter traceerbaar en beter afgestemd op toekomstige rapportagebehoeften. Het verminderde ook de afhankelijkheid van hoe individuele systemen gegevens opslaan, waardoor analisten één betrouwbaar overzicht kregen van alle processen.

Wat betekent event sourcing voor AI en gegevensagenten?

Moderne AI, van voorspellende modellen tot generatieve agents, is afhankelijk van context.
Large Language Models (LLM’s) en data agents hebben schone data nodig en inzicht in hoe en waarom die data zijn veranderd.

Wanneer je datamodel alleen de laatste status opslaat, verlies je de opeenvolging van gebeurtenissen die gedrag verklaart. Technieken als Slowly Changing Dimensions (SCD’s) of snapshots kunnen delen van die geschiedenis vastleggen: ze vertellen je wat er veranderd is en wanneer.
Maar ze laten niet altijd zien hoe dingen veranderden of in welke volgorde gebeurtenissen plaatsvonden.

Event sourcing bewaart die volledige reeks.
Het legt elk betekenisvol moment vast terwijl het gebeurt, waardoor AI-systemen en gegevensanalisten een verhaal hebben om over te redeneren. Een complete tijdlijn van beslissingen, interacties en uitkomsten. Die rijkere context helpt modellen en agents om niet alleen de stand van zaken te begrijpen, maar ook het verhaal erachter.

Dit maakt het onmisbaar in het tijdperk van AI:

• Gespreks- en agentiële AI-systemen kunnen antwoord geven op de vraag “hoe zijn we hier gekomen?” en “wat gebeurt er nu?” door gebruik te maken van echte gebeurtenispaden, niet van statische aggregaten.
  
• Generatieve AI kan gebeurtenisgeschiedenissen gebruiken als basisgegevens, waardoor hallucinaties worden verminderd en contextueel accurate reacties worden geproduceerd die de werkelijke oorzaak en gevolg weerspiegelen.
  
• Voorspellende modellen hebben ook baat bij gegevens afkomstig van gebeurtenissen. Ze worden meestal getraind op geaggregeerde kenmerken in plaats van ruwe gebeurtenissen, maar die kenmerken worden nauwkeuriger en flexibeler als ze zijn afgeleid van een volledige geschiedenis met tijdstempels.
  
• De AI-observeerbaarheid verbetert, omdat event logs het makkelijker maken om modelinputs, beslissingen en feedback loops in de loop van de tijd te traceren.
  

Event sourcing doet meer dan traceerbaarheid garanderen; het geeft structuur aan tijd en context.
Het geeft je gegevens een levend geheugen, waar AI van kan leren, mee kan interageren en door kan groeien.

Wat zijn de gemeenschappelijke uitdagingen bij het invoeren van event sourcing?

Voor veel teams is event sourcing even wennen. Niet omdat het concept zo ingewikkeld is, maar omdat het vertrouwde gewoonten op de proef stelt. Dit zijn enkele van de veelvoorkomende vragen of aarzelingen die we van klanten horen, samen met de manieren die we hebben geleerd om ermee om te gaan.

Het is een andere manier van denken

Je modelleert “wat er is gebeurd” in plaats van “wat het is”. Dat vereist een mentale verschuiving voor ontwikkelaars en analisten.

Oplossing:

Maak het niet te ingewikkeld. Behandel gebeurtenissen als journaalposten in de boekhouding: elke gebeurtenis legt een feit in de tijd vast. Gebruik naamgevingsconventies zoals _event_log, toon stromen in eenvoudige diagrammen en bied voorbeeldquery’s aan. Mensen hebben het sneller door dan je denkt, vooral als de structuur consistent is in verschillende systemen.
Het is geen probleem. Het is gewoon een nieuwe standaard.

Evenementvolumes groeien snel

Als je alles opslaat, zullen je tabellen snel groeien. Vooral in hoogfrequente domeinen zoals clickstreamgegevens.

Oplossing:

• Gebruik cloud-native tools met schaalbare opslag (bijv. Snowflake, BigQuery, Databricks)
  
• Introduceer een gelaagd model: onbewerkte eventlogs eronder, statusweergaven erboven. Analisten bevragen de vereenvoudigde laag, niet de onbewerkte logbestanden.
  

De huidige staat reconstrueren is een inspanning

Wil je de laatste status van iets weten? Dan moet je alle gebeurtenissen tot op dat moment verwerken.

Oplossing:

• Gematerialiseerde statustabellen bouwen die periodiek worden bijgewerkt
  
  

Niet alle systemen bieden gebeurtenissen

Sommige systemen (zoals CRM’s of ERP’s) geven alleen de huidige status weer, niet de veranderingen in de loop van de tijd.

Oplossing:
Gebruik snapshottechnieken (bv. dbt snapshots of Change Data Capture) om wijzigingen te detecteren en ze om te zetten in synthetische gebeurtenissen. Het is niet zo elegant, maar het brengt je dicht bij een echt gebeurtenissenlogboek.

De meeste hiervan zijn geen echte blokkades, maar eerder praktische overwegingen die een duidelijkere aanpak vereisten.

Kies verandering boven staat

Event sourcing geeft je meer dan technische controle; het geeft je strategische duidelijkheid en vertrouwen.

Je gaat van statische momentopnames naar een levend verslag van hoe dingen in de loop van de tijd veranderen.
Die verschuiving verandert je datawarehouse van een fragiel systeem van feiten in een veerkrachtig systeem van duidelijkheid.

Als je niet alleen begrijpt wat er is gebeurd, maar ook hoe en waarom, bereik je een nieuw niveau van aanpassingsvermogen. Betrouwbaardere gegevens. Duidelijkere inzichten. En een fundament dat met uw bedrijf meegroeit.

Wil je statustabellen omzetten in gebeurtenissen?
Weet je niet zeker wanneer je SCD vs. evenementen moet gebruiken?
Benieuwd of jouw gereedschap dit model ondersteunt?

We maken graag een praatje.