Event Sourcing in defensiesystemen: onveranderlijke audittrails voor militaire gegevens

Defensie-informatiesystemen hebben een vereiste die commerciële applicaties zelden tegenkomen: elke toestandsverandering in het systeem moet permanent worden vastgelegd, manipulatiebestendig en reproduceerbaar. Post-operationele analyse (nabeschouwing), juridische verantwoording voor inzetten, inlichtingenwaardebeoordelingen van verzamelde gegevens — allemaal vereisen een autoritatieve, onveranderlijke registratie van wat het systeem wist en welke beslissingen op elk tijdstip werden genomen. Event Sourcing is het architectuurpatroon dat dit biedt, en begrijpen hoe het correct te implementeren in defensiecontexten is het onderwerp van dit artikel.

Event Sourcing versus CRUD: het kernverschil

In een traditioneel CRUD-systeem (Create, Read, Update, Delete) wordt toestand opgeslagen als de huidige waarde van elke entiteit. Wanneer een trackpositie wordt bijgewerkt, wordt de vorige positie overschreven. Wanneer een SITREP wordt herzien, kan de vorige versie al dan niet worden bewaard afhankelijk van hoe de applicatie is ontworpen. De systeemtoestand op een bepaald historisch moment is niet intrinsiek herstelbaar vanuit de database — het vereist expliciete versioneringsontwerpsKeuzes om aanwezig te zijn.

Event Sourcing keert dit model om. Toestand wordt nooit direct opgeslagen. In plaats daarvan wordt elke wijziging in systeemtoestand opgeslagen als een gebeurtenis — een onveranderlijk, alleen-toevoegen-record. De gebeurtenisopslag bevat: TrackPositionUpdated op tijdstip T1 naar coördinaten X1; TrackPositionUpdated op tijdstip T2 naar coördinaten X2; TrackIdentityAttributed op tijdstip T3 naar eenheidsaanduiding Y. De huidige toestand van een track is altijd berekenbaarbaar door de gebeurtenisstroom van het begin te herhalen. De gebeurtenisopslag zelf is een alleen-toevoegen-logboek — geen gebeurtenis wordt ooit gewijzigd of verwijderd.

De operationele gevolg is dat elke versie van elke entiteit altijd beschikbaar is. "Wat wist het systeem over deze track om 14:23:07?" is beantwoordbaar door gebeurtenissen tot dat tijdstempel te herhalen. Deze mogelijkheid is operationeel essentieel voor defensiesystemen en vrijwel gratis te implementeren als de architectuur er van het begin voor is ontworpen.

Defensiegebruiksscenario's voor Event Sourcing

SITREP-geschiedenis: Situatierapporten worden frequent herzien naarmate nieuwe inlichtingen binnenkomen. In een CRUD-systeem weerspiegelt de huidige SITREP de laatste beoordeling maar de geschiedenis van hoe die beoordeling zich ontwikkelde is verloren. In een event-sourced systeem is elke herziening een gebeurtenis — SITREPCreated, SITREPRevised, SITREPApproved, SITREPDisseminated — en de volledige geschiedenis is altijd opvraagbaar. Na een operatie kunnen inlichtingenanalisten exact reconstrueren wat bekend was en wanneer, wat essentieel is voor schadebeoordelingen en verbetering van inlichtingenprocessen.

Trackupdatelogboek: De kinematische geschiedenis van elke track in het systeem — elke positie-update, elke identiteitstoeschrijving, elke zekerheidsverandering — is het ruwe materiaal voor patroon-van-leven-analyse, routereconstructie en post-operationele analyse. Event Sourcing maakt deze geschiedenis intrinsiek aan de architectuur in plaats van een add-on. Een TrackUpdated-gebeurtenis bevat de volledige trackstoestand bij updatetijd, de bron van de update, de analist of het algoritme verantwoordelijk en de vorige toestand die wordt vervangen.

Commandobeslissing herhalen voor nabeschouwing (AAR): Een inzet betrof een beslissing om te vuren op tijdstip T op basis van de systeemtoestand op tijdstip T. De AAR moet de systeemtoestand op tijdstip T reconstrueren: welke tracks zichtbaar waren, welke dreigingsbeoordelingen actueel waren, welke regels van inzet van toepassing waren, welke orders actief waren. Event Sourcing maakt dit mogelijk door de gebeurtenisstroom te herhalen naar tijdstip T en de systeemtoestand op dat punt te materialiseren.

Event store-technologieën

EventStoreDB is een specifiek gebouwde event store-database, ontworpen voor event-sourced architecturen. Het biedt native stroompartitionering (gebeurtenissen zijn georganiseerd op aggregaatidentificator, zodat alle gebeurtenissen voor track-ID 12345 in stroom "track-12345" zijn), native abonnementfeeds voor het bouwen van projecties en ingebouwde ondersteuning voor optimistische gelijktijdigheidscontrole. EventStoreDB is een redelijke eerste keuze voor nieuwe event-sourced defensiesystemen als de operationele beperkingen een speciale databaseproces toestaan.

Apache Kafka als gebeurtenislogboek: De alleen-toevoegen, gepartitioneerde logboekarchitectuur van Kafka past goed bij event-sourcing-vereisten. Kafka-onderwerpen partitioneren gebeurtenissen op aggregaattype; binnen een onderwerp zijn gebeurtenissen geordend op partitie en offset. Het consumptiegroep-mechanisme stelt meerdere projecties in staat dezelfde gebeurtenisstroom te consumeren op onafhankelijke offsets. Het gedistribueerde ontwerp van Kafka biedt fouttolerantie die EventStoreDB aanvullende configuratie nodig heeft om te evenaren. Voor defensiesystemen die al Kafka gebruiken voor ingestiepijplijnen, vermijdt het gebruik van Kafka als de gebeurtenisopslag het introduceren van een tweede gespecialiseerde database.

PostgreSQL met JSONB alleen-toevoegen-tabellen: Voor systemen waarbij het introduceren van een speciale gebeurtenisopslag niet haalbaar is, is PostgreSQL met een alleen-toevoegen-tabel en JSONB-gebeurtenispayloads een praktisch alternatief. Het tabelschema: event_id (UUID), aggregate_type (VARCHAR), aggregate_id (UUID), event_type (VARCHAR), event_data (JSONB), occurred_at (TIMESTAMPTZ), recorded_at (TIMESTAMPTZ), recorded_by (VARCHAR). Een trigger of applicatieniveaubeperking voorkomt UPDATE- en DELETE-bewerkingen op de tabel. Dit biedt Event Sourcing-semantiek zonder een speciale technologie.

Toestand herbouwen: projecties, snapshots en herhalingsprestaties

De huidige toestand van een entiteit herbouwen door zijn volledige gebeurtenisgeschiedenis van het begin te herhalen is rekenkundig duur voor entiteiten met lange geschiedenissen. Een track die 50.000 positie-updates heeft ontvangen over 30 dagen vereist 50.000 gebeurtenissen te herhalen om de huidige toestand te berekenen. Dit is de prestatieuitdaging van Event Sourcing.

De standaardoplossing is snapshotting: periodiek de huidige toestand van een entiteit materialiseren en naast de gebeurtenisstroom opslaan. Bij het herbouwen van toestand laadt het systeem de meest recente snapshot en herhaalt alleen gebeurtenissen na de snapshot-tijdstempel. Een track met 50.000 totale gebeurtenissen maar een snapshot na 49.900 gebeurtenissen hoeft slechts 100 gebeurtenissen te herhalen. Snapshotfrequentie is een afstembare parameter: frequentere snapshots verbeteren leeslatentie ten koste van meer opslag.

Projecties zijn leesgeoptimaliseerde weergaven afgeleid van de gebeurtenisstroom. Een "huidige trackposities"-projectie materialiseert de laatste positie van elke track door TrackPositionUpdated-gebeurtenissen te consumeren. Een "trackgeschiedenis per eenheid"-projectie materialiseert alle positiegeschiedenis voor elke eenheid. Projecties kunnen van scratch worden herbouwd door de volledige gebeurtenisstroom te herhalen, wat is hoe u herstelt van een beschadigde projectiedatabase zonder gegevens te verliezen.

Juridische en compliancedimensies

De juridische vereisten voor defensiegegevensbewaring variëren aanzienlijk per nationaal rechtsgebied en operatietype. Minimaal vereisen de meeste defensieprogramma's: bewijs van gegevensintegriteit (het opgeslagen record is niet gewijzigd na aanmaak), chain-of-custody-records (wie elk gegevensitem heeft geopend en verwerkt) en naleving van bewaarperiodes (gegevens worden bewaard voor de vereiste periode en veilig verwijderd daarna). Event Sourcing biedt intrinsiek bewijs van gegevensintegriteit — de alleen-toevoegen-opslag is structureel resistent tegen wijziging. Chain of custody wordt geboden door de gebeurtenismetadata (recorded_by, processing_system_id-velden). Compliancenaleving vereist expliciete beleidsafdwinging op infrastructuurniveau.