Event Sourcing în sistemele de apărare: Trasee de audit imuabile pentru datele militare

Sistemele informaționale de apărare au o cerință cu care aplicațiile comerciale se confruntă rareori: fiecare modificare de stare din sistem trebuie înregistrată permanent, rezistentă la falsificare și reproductibilă. Analiza post-operațională (analiza post-acțiune), responsabilitatea legală pentru angajamente, evaluările valorii de informații ale datelor colectate — toate necesită o înregistrare autorizată și imuabilă a ceea ce știa sistemul și ce decizii s-au luat în fiecare moment. Event sourcing este modelul arhitectural care oferă acest lucru, iar înțelegerea modului de implementare corectă în contexte de apărare face obiectul acestui articol.

Event sourcing vs CRUD: diferența fundamentală

Într-un sistem CRUD tradițional (Create, Read, Update, Delete), starea este stocată ca valoarea curentă a fiecărei entități. Când poziția unei urme este actualizată, poziția anterioară este suprascrisă. Când un SITREP este revizuit, versiunea anterioară poate sau nu să fie păstrată în funcție de modul în care este proiectată aplicația. Starea sistemului la orice moment istoric dat nu este intrinsec recuperabilă din baza de date — necesită alegeri explicite de proiectare a versionării.

Event sourcing inversează acest model. Starea nu este niciodată stocată direct. În schimb, fiecare modificare a stării sistemului este stocată ca un eveniment — o înregistrare imuabilă, numai-adăugare. Magazinul de evenimente conține: TrackPositionUpdated la momentul T1 la coordonatele X1; TrackPositionUpdated la momentul T2 la coordonatele X2; TrackIdentityAttributed la momentul T3 la desemnarea unității Y. Starea curentă a unei urme este întotdeauna calculabilă prin redarea fluxului de evenimente de la început. Magazinul de evenimente în sine este un jurnal numai-adăugare — niciun eveniment nu este niciodată modificat sau șters.

Consecința operațională este că fiecare versiune a fiecărei entități este întotdeauna disponibilă. „Ce știa sistemul despre această urmă la 14:23:07?" este o întrebare la care se poate răspunde prin redarea evenimentelor până la acea marcă temporală. Această capacitate este esențială operațional pentru sistemele de apărare și practic gratuită de implementat dacă arhitectura este proiectată pentru aceasta de la bun început.

Cazuri de utilizare în apărare pentru event sourcing

Istoricul SITREP: Rapoartele de situație sunt revizuite frecvent pe măsură ce sosesc noi informații. Într-un sistem CRUD, SITREP-ul curent reflectă cea mai recentă evaluare, dar istoricul evoluției acestei evaluări se pierde. Într-un sistem bazat pe event sourcing, fiecare revizie este un eveniment — SITREPCreated, SITREPRevised, SITREPApproved, SITREPDisseminated — iar istoricul complet este întotdeauna interogabil. După o operațiune, analiștii de informații pot reconstrui exact ce se știa și când, ceea ce este esențial pentru evaluarea daunelor de luptă și îmbunătățirea procesului de informații.

Jurnalul de actualizare a urmelor: Istoricul cinematic al fiecărei urme din sistem — fiecare actualizare de poziție, fiecare atribuire de identitate, fiecare modificare de încredere — este materia primă pentru analiza modelului de viață, reconstrucția rutei și analiza post-operațională. Event sourcing face ca acest istoric să fie intrinsec arhitecturii, nu un add-on. Un eveniment TrackUpdated conține starea completă a urmei la momentul actualizării, sursa actualizării, analistul sau algoritmul responsabil și starea anterioară care este suplinită.

Redarea deciziilor de comandă pentru AAR (Analiza post-acțiune): Un angajament a implicat o decizie de deschidere a focului la momentul T pe baza stării sistemului la momentul T. AAR trebuie să reconstruiască starea sistemului la momentul T: ce urme erau vizibile, ce evaluări de amenințare erau curente, ce reguli de angajare se aplicau, ce ordine erau active. Event sourcing permite acest lucru prin redarea fluxului de evenimente până la momentul T și materializarea stării sistemului la acel punct.

Tehnologii de stocare a evenimentelor

EventStoreDB este o bază de date de stocare a evenimentelor construită special, proiectată specific pentru arhitecturi bazate pe event sourcing. Oferă partiționare nativă a fluxurilor (evenimentele sunt organizate după identificatorul agregat, astfel încât toate evenimentele pentru ID-ul urmei 12345 sunt în fluxul „track-12345"), fluxuri native de abonament pentru construirea proiecțiilor și suport integrat pentru controlul optimist al concurenței. EventStoreDB este o primă alegere rezonabilă pentru sistemele noi de apărare bazate pe event sourcing dacă constrângerile operaționale permit un proces dedicat de baze de date.

Apache Kafka ca jurnal de evenimente: Arhitectura jurnalului numai-adăugare, partiționat a Kafka corespunde îndeaproape cerințelor de event sourcing. Subiectele Kafka partiționează evenimentele după tipul de agregat; în cadrul unui subiect, evenimentele sunt ordonate după partiție și offset. Mecanismul grupului de consumatori permite mai multor proiecții să consume același flux de evenimente la offset-uri independente. Proiectarea distribuită a Kafka oferă toleranță la erori pe care EventStoreDB necesită configurație suplimentară pentru a o egaliza. Pentru sistemele de apărare care folosesc deja Kafka pentru pipeline-urile de ingestie, utilizarea Kafka ca magazin de evenimente evită introducerea unei a doua baze de date specializate.

PostgreSQL cu tabele de adăugare JSONB: Pentru sistemele în care introducerea unui magazin dedicat de evenimente nu este fezabilă, PostgreSQL cu un tabel numai-adăugare și sarcini utile JSONB de evenimente este o alternativă practică. Schema tabelului: event_id (UUID), aggregate_type (VARCHAR), aggregate_id (UUID), event_type (VARCHAR), event_data (JSONB), occurred_at (TIMESTAMPTZ), recorded_at (TIMESTAMPTZ), recorded_by (VARCHAR). Un declanșator sau o constrângere la nivel de aplicație previne operațiunile UPDATE și DELETE pe tabel. Aceasta oferă semantica event sourcing fără o tehnologie dedicată.

Reconstruirea stării: proiecții, instantanee și performanța redării

Reconstruirea stării curente a unei entități prin redarea istoricului complet al evenimentelor sale de la început este costisitoare computațional pentru entitățile cu istorii lungi. O urmă care a primit 50.000 de actualizări de poziție în 30 de zile necesită redarea a 50.000 de evenimente pentru a calcula starea sa curentă. Aceasta este provocarea de performanță a event sourcing.

Soluția standard este crearea instantaneelor: materializarea periodică a stării curente a unei entități și stocarea ei alături de fluxul de evenimente. La reconstruirea stării, sistemul încarcă cel mai recent instantaneu și redă numai evenimentele după marca temporală a instantaneului. O urmă cu 50.000 de evenimente totale, dar un instantaneu luat după 49.900 de evenimente necesită redarea a doar 100 de evenimente. Frecvența instantaneelor este un parametru ajustabil: instantaneele mai frecvente îmbunătățesc latența de citire cu costul unui spațiu de stocare mai mare.

Proiecțiile sunt vizualizări optimizate pentru citire derivate din fluxul de evenimente. O proiecție „pozițiile curente ale urmelor" materializează cea mai recentă poziție a fiecărei urme prin consumarea evenimentelor TrackPositionUpdated. O proiecție „istoricul urmelor pe unitate" materializează întregul istoric al pozițiilor pentru fiecare unitate. Proiecțiile pot fi reconstruite de la zero prin redarea fluxului complet de evenimente, ceea ce este modul în care vă recuperați dintr-o bază de date de proiecții coruptă fără pierdere de date.

Dimensiunile legale și de conformitate

Cerințele legale pentru retenția datelor de apărare variază semnificativ în funcție de jurisdicția națională și tipul de operațiune. La minimum, majoritatea programelor de apărare necesită: dovezi de integritate a datelor (înregistrarea stocată nu a fost modificată de la creare), înregistrări ale lanțului de custodie (cine a accesat și gestionat fiecare element de date) și conformitatea perioadei de retenție (datele sunt păstrate pentru perioada necesară și șterse în siguranță după aceea). Event sourcing oferă dovezi de integritate a datelor în mod intrinsec — magazinul numai-adăugare este structural rezistent la modificări. Lanțul de custodie este asigurat de metadatele evenimentelor (câmpurile recorded_by, processing_system_id). Conformitatea retenției necesită aplicarea explicită a politicilor la nivelul infrastructurii.