Event Sourcing in Verteidigungssystemen: Unveränderliche Prüfpfade für militärische Daten

Militärische Informationssysteme der Bundeswehr haben eine Anforderung, mit der kommerzielle Anwendungen selten konfrontiert sind: Jede Zustandsänderung im System muss dauerhaft aufgezeichnet, manipulationssicher und reproduzierbar sein. Nachoperationsanalyse (After-Action Review), rechtliche Verantwortlichkeit für Gefechtshandlungen, Geheimdienstliche Bewertung gesammelter Daten — all das erfordert eine maßgebliche, unveränderliche Aufzeichnung dessen, was das System wusste und welche Entscheidungen zu jedem Zeitpunkt getroffen wurden. Event Sourcing ist das Architekturmuster, das dies ermöglicht, und das Verständnis, wie es korrekt in Verteidigungskontexten implementiert wird, ist Gegenstand dieses Artikels.

Event Sourcing vs. CRUD: Der grundlegende Unterschied

In einem traditionellen CRUD-System (Create, Read, Update, Delete) wird der Zustand als aktueller Wert jeder Entität gespeichert. Wenn eine Spurposition aktualisiert wird, wird die vorherige Position überschrieben. Wenn ein SITREP überarbeitet wird, kann die vorherige Version je nach Anwendungsdesign erhalten bleiben oder nicht. Der Systemzustand zu einem beliebigen historischen Zeitpunkt ist nicht inhärent aus der Datenbank wiederherstellbar — das erfordert explizite Versionierungsdesignentscheidungen.

Event Sourcing invertiert dieses Modell. Der Zustand wird nie direkt gespeichert. Stattdessen wird jede Änderung des Systemzustands als Ereignis gespeichert — ein unveränderlicher, nur-anhängen-Datensatz. Der Ereignisspeicher enthält: TrackPositionUpdated zum Zeitpunkt T1 mit Koordinaten X1; TrackPositionUpdated zum Zeitpunkt T2 mit Koordinaten X2; TrackIdentityAttributed zum Zeitpunkt T3 mit Einheitsbezeichnung Y. Der aktuelle Zustand einer Spur ist immer durch Wiedergabe des Ereignisstroms von Anfang an berechenbar. Der Ereignisspeicher selbst ist ein Nur-Anhängen-Protokoll — kein Ereignis wird jemals geändert oder gelöscht.

Die operationale Konsequenz ist, dass jede Version jeder Entität immer verfügbar ist. «Was wusste das System um 14:23:07 über diese Spur?» ist durch Wiedergabe von Ereignissen bis zu diesem Zeitstempel beantwortbar. Diese Fähigkeit ist für Bundeswehr-Systeme operativ essenziell und im Wesentlichen kostenlos zu implementieren, wenn die Architektur von Anfang an darauf ausgelegt ist.

Bundeswehr-Anwendungsfälle für Event Sourcing

SITREP-Historie: Lageberichte werden häufig überarbeitet, wenn neue Geheimdienstinformationen eintreffen. In einem CRUD-System spiegelt der aktuelle SITREP die neueste Bewertung wider, aber die Geschichte, wie sich diese Bewertung entwickelt hat, geht verloren. In einem event-sourcingten System ist jede Überarbeitung ein Ereignis — SITREPCreated, SITREPRevised, SITREPApproved, SITREPDisseminated — und die vollständige Geschichte ist immer abfragbar. Nach einer Operation können Geheimdienstanalysten genau rekonstruieren, was wann bekannt war, was für die Kampfschadensbewertung und die Verbesserung von Geheimdienstprozessen unerlässlich ist.

Spur-Aktualisierungsprotokoll: Die kinematische Geschichte jeder Spur im System — jede Positionsaktualisierung, jede Identitätszuweisung, jede Konfidenzänderung — ist das Rohmaterial für Verhaltensmusteranalyse, Routenrekonstruktion und Nachoperationsanalyse. Event Sourcing macht diese Geschichte zur inhärenten Eigenschaft der Architektur statt zu einem Zusatz. Ein TrackUpdated-Ereignis enthält den vollständigen Spurzustand zum Aktualisierungszeitpunkt, die Quelle der Aktualisierung, den verantwortlichen Analysten oder Algorithmus und den vorherigen Zustand, der ersetzt wird.

Befehlsentscheidungswiederholung für AAR: Ein Gefecht beinhaltete eine Feuereröffnungsentscheidung zum Zeitpunkt T basierend auf dem Systemzustand zum Zeitpunkt T. Das AAR muss den Systemzustand zum Zeitpunkt T rekonstruieren: welche Spuren sichtbar waren, welche Bedrohungsbewertungen aktuell waren, welche Einsatzregeln galten, welche Befehle aktiv waren. Event Sourcing ermöglicht dies durch Wiedergabe des Ereignisstroms bis Zeitpunkt T und Materialisierung des Systemzustands an diesem Punkt.

Ereignisspeicher-Technologien

EventStoreDB ist eine zweckgebaute Ereignisspeicher-Datenbank, speziell für event-sourcing-Architekturen konzipiert. Sie bietet natives Stream-Partitionierung (Ereignisse sind nach Aggregatkennung organisiert, sodass alle Ereignisse für Spur-ID 12345 im Stream «track-12345» liegen), native Abonnement-Feeds zum Erstellen von Projektionen und eingebaute Unterstützung für optimistische Parallelitätskontrolle. EventStoreDB ist eine vernünftige erste Wahl für neue Bundeswehr-Systeme mit Event Sourcing, wenn die operativen Einschränkungen einen dedizierten Datenbankprozess erlauben.

Apache Kafka als Ereignisprotokoll: Kafkas Nur-Anhängen-Protokoll-Architektur mit Partitionierung entspricht eng den Anforderungen des Event Sourcings. Kafka-Topics partitionieren Ereignisse nach Aggregattyp; innerhalb eines Topics sind Ereignisse nach Partition und Offset geordnet. Der Consumer-Group-Mechanismus ermöglicht mehreren Projektionen, denselben Ereignisstrom bei unabhängigen Offsets zu konsumieren. Kafkas verteiltes Design bietet Fehlertoleranz, die EventStoreDB zusätzlicher Konfiguration bedarf, um zu erreichen. Für Bundeswehr-Systeme, die bereits Kafka für Erfassungspipelines verwenden, vermeidet die Verwendung von Kafka als Ereignisspeicher die Einführung einer zweiten spezialisierten Datenbank.

PostgreSQL mit JSONB-Nur-Anhängen-Tabellen: Für Systeme, bei denen die Einführung eines dedizierten Ereignisspeichers nicht durchführbar ist, ist PostgreSQL mit einer Nur-Anhängen-Tabelle und JSONB-Ereignisnutzlasten eine praktische Alternative. Das Tabellenschema: event_id (UUID), aggregate_type (VARCHAR), aggregate_id (UUID), event_type (VARCHAR), event_data (JSONB), occurred_at (TIMESTAMPTZ), recorded_at (TIMESTAMPTZ), recorded_by (VARCHAR). Ein Trigger oder eine Einschränkung auf Anwendungsebene verhindert UPDATE- und DELETE-Operationen auf der Tabelle. Dies bietet Event-Sourcing-Semantik ohne eine dedizierte Technologie.

Zustandswiederherstellung: Projektionen, Snapshots und Wiedergabeleistung

Die Wiederherstellung des aktuellen Zustands einer Entität durch Wiedergabe ihrer vollständigen Ereignishistorie von Anfang an ist für Entitäten mit langer Historie rechenintensiv. Eine Spur, die über 30 Tage 50.000 Positionsaktualisierungen erhalten hat, erfordert die Wiedergabe von 50.000 Ereignissen, um ihren aktuellen Zustand zu berechnen. Dies ist die Leistungsherausforderung des Event Sourcings.

Die Standardlösung ist Snapshotting: periodisches Materialisieren des aktuellen Zustands einer Entität und dessen Speicherung neben dem Ereignisstrom. Bei der Zustandswiederherstellung lädt das System den neuesten Snapshot und gibt nur Ereignisse nach dem Snapshot-Zeitstempel wieder. Eine Spur mit insgesamt 50.000 Ereignissen, aber einem Snapshot nach 49.900 Ereignissen, erfordert nur die Wiedergabe von 100 Ereignissen. Die Snapshot-Häufigkeit ist ein konfigurierbarer Parameter: häufigere Snapshots verbessern die Leseverzögerung auf Kosten von mehr Speicherplatz.

Projektionen sind leseoptimierte Ansichten, die aus dem Ereignisstrom abgeleitet werden. Eine Projektion «aktuelle Spurpositionen» materialisiert die neueste Position jeder Spur durch Konsum von TrackPositionUpdated-Ereignissen. Eine Projektion «Spurhistorie nach Einheit» materialisiert die gesamte Positionshistorie für jede Einheit. Projektionen können von Grund auf neu aufgebaut werden, indem der vollständige Ereignisstrom wiedergegeben wird, was die Art und Weise ist, wie man nach einer beschädigten Projektionsdatenbank ohne Datenverlust wiederhergestellt.

Rechtliche und Compliance-Dimensionen

Die rechtlichen Anforderungen an die Aufbewahrung von Verteidigungsdaten variieren erheblich nach nationaler Zuständigkeit und Operationsart. Für Bundeswehr-Systeme sind mindestens erforderlich: Datenintegritätsnachweise (der gespeicherte Datensatz wurde seit der Erstellung nicht modifiziert), Dokumentation der Verwahrungskette (wer auf jeden Datenelement zugegriffen und es verarbeitet hat) und Aufbewahrungszeitraum-Compliance (Daten werden für den erforderlichen Zeitraum aufbewahrt und danach sicher gelöscht). Event Sourcing liefert Datenintegritätsnachweise inhärent — der Nur-Anhängen-Speicher ist strukturell manipulationsresistent. Die Verwahrungskette wird durch Ereignis-Metadaten bereitgestellt (Felder recorded_by, processing_system_id). Die Aufbewahrungszeitraum-Compliance erfordert explizite Richtliniendurchsetzung auf Infrastrukturebene.