Event-Driven Kernel

Was ist ein Event-Driven-Kernel?

Ein Event-Driven Core (EDC) ist das "Rückgrat' einer Architektur, in der geschäftliche Fakten als unveränderliche Ereignisse erfasst und verbreitet werden und der Rest der Funktionalität (Lesen, Integration, Analyse, Caches, Benachrichtigungen) auf dem Fluss dieser Ereignisse aufbaut. Der Kernel legt den Ereignisvertrag, die Bereitstellungsregeln und die Invarianten der Ordnung/Idempotenz fest und bietet eine schwache Konnektivität und Skalierbarkeit.

Die Grundidee: Zuerst den Fakt (Kern) aufschreiben und dann selbstständig anreichern und in die gewünschten Modelle projizieren. Dies verringert die Konnektivität und erhöht die Widerstandsfähigkeit gegen Teilausfälle.

EDC-Ziele und -Eigenschaften

Die Wahrheit der Tatsachen: Jedes Ereignis ist eine unveränderliche Aufzeichnung des „Was geschah“.
Schwache Konnektivität: Die Erzeuger kennen die Verbraucher nicht; Erweiterung des Systems durch Hinzufügen von Abonnenten.
Skalierung: horizontales Wachstum nach Parties/Topics, unabhängige Verbraucher.
Beobachtbarkeit und Audit: End-to-End-IDs, Reproduzierbarkeit, Retentionen und Reproliferation.
Kontrollierte Evolution: Schaltungsversionen, Kompatibilität, Deprecation.

Architektonische Komponenten

1. Bus-/Event-Broker: Kafka/NATS/Pulsar/SNS + SQS - Kanäle, Parties, Retentionen.
2. Scheme Registry: JSON Schema/Avro/Protobuf für Kompatibilität und Evolution.
3. Outbox/CDC-Loop: Atomare Faktenfixierung + Veröffentlichung ohne „Double Writing“.
4. Projektionen/Lesungen (CQRS): Materialisierte Ansichten für schnelle Abfragen.
5. Saga/Orchestrierung: Koordination langlebiger Prozesse durch Events/Teams.
6. Anreicherung: Einzelne Topics' .enriched '/' .derived 'ohne Auswirkung auf den kritischen Pfad.
7. Observability: Tracing, Logging, Metriken nach Ereignissen und Verzögerungen.

Ereignismodell

Ereignistypen

Domain Events: Geschäftliche Fakten ('payment. authorized`, `kyc. approved`).
Integration Events: Fokussierung auf externe Systeme (stabil, ändern sich langsam).
Change Data Capture (CDC): Technische Änderungen am Datensatz (für Migrationen/Integrationen verwenden).
Audit/Telemetrie: Handlungen der Akteure, Sicherheit, SLA.

Erforderliche Attribute (Kernel)

json
{
"event_id": "uuid",
"event_type": "payment. authorized. v1",
"occurred_at": "2025-10-31T11:34:52Z",
"producer": "payments-service",
"subject": { "type": "payment", "id": "pay_123" },
"payload": { "amount": 1000, "currency": "EUR", "method": "card" },
"schema_version": 1,
"trace_id": "abc123",
"partition_key": "pay_123"
}

Empfehlungen: 'event _ id' ist global eindeutig, 'partition _ key' gibt die Reihenfolge für die Entität vor, 'trace _ id' stellt die Korrelation sicher.

Semantik der Lieferung und Idempotenz

At-least-once (Standard bei vielen Brokern): Verbraucher sind verpflichtet, idempotent zu sein.
At-most-once: Nur für kleinere Telemetrien akzeptabel.
Exactly-once: erreicht auf Fluss- und Speicherebene durch Transaktionen/idempotente Schlüssel/Gießkannen (teurer, guter Grund erforderlich).

Vorlage für Verbraucher-Idempotenz

Dedup-Tabelle für 'event _ id '/' (event_id, consumer_id)' mit TTL ≥ topic retention.
Upsert statt insert; Versionierung der Projektionen durch 'sequence '/' occurred _ at'.
Transaktionen innerhalb einer Transaktion: Markierung „gesehen“ + Statusänderung.

Reihenfolge und Partitionierung

Garantierte Ordnung innerhalb der Partei.
Wählen Sie' partition _ key 'so, dass alle Ereignisse einer Aggregat-Entität in einen Batch fallen (' user _ id', 'payment _ id').
Vermeiden Sie „Hot Keys“: Hash mit Salz/Sub-Keys, wenn die Last verteilt werden soll.

Diagramme und Entwicklung

Additiv-first: neue optionale Felder, Verbot von Typ-/Semantikänderungen ohne Major-Version.
Kompatibilität: BACKWARD/FORWARD im Scheme-Register; CI blockiert inkompatible Änderungen.
Benennung: 'Domäne. action. v{major}` (`payment. authorized. v1`).
Migrationen: Veröffentlichen Sie die Paare' v1 'und' v2 'parallel, sorgen Sie für Doppelstrahlung (Dual-Write über Outbox), schießen Sie' v1 'nach dem Übergang.

Outbox и CDC

Outbox (empfohlen für Transaktionsservices)

1. In einer DB-Transaktion: Speichern Sie den Domäneneintrag und das Ereignis in der Outbox.
2. Die Hintergrund-Kneipe liest die Outbox, veröffentlicht sie an den Broker, markiert sie mit „gesendet“.
3. Garantien: kein „Verlust“ der Tatsache bei Stürzen, keine Nicht-Synchronisation.

CDC (Change Data Capture)

Geeignet für bestehende Systeme/Migrationen; Quelle ist das DB-Replikationsprotokoll.
Erfordert Filterung/Transcodierung in Domänenereignisse (übertragen Sie keine „rohen“ Tabellen nach außen).

CQRS und Projektionen

Befehle ändern den Zustand (oft synchron), Ereignisse bilden Projektionen (asynchron).
Projektionen sind für Abfragen (Suche, Listen, Berichte) konzipiert und werden von Abonnenten aktualisiert.
Temporäre Nicht-Synchronisation ist die Norm: Zeigen Sie eine stabile UX („Daten werden in wenigen Sekunden aktualisiert“).

Sagas: Prozesse koordinieren

Orchestrierung: Ein Koordinator schickt Teams und wartet auf Veranstaltungen.
Choreographie: Die Teilnehmer reagieren auf die Ereignisse des anderen (einfacher, erfordert aber Disziplin in den Verträgen).
Regeln: klare Entschädigungen und Auszeiten, wiederholbare Schritte, idempotente Handler.

Beobachtbarkeit

Trace/Span: Wirf 'trace _ id '/' span _ id' durch die Header, wenn Ereignisse erzeugt werden.
Metriken: Verbraucherfehler, Veröffentlichungs-/Verbrauchsrate, Dead-Letter-Rate, Anteil der Deduplizierungen.
DLQ/parking lot: fehlgeschlagene Nachrichten - in einem separaten Topic mit alert; Sorgen Sie für eine Neubearbeitung.

Sicherheit und Compliance

Datenklassifizierung: Der Kern enthält nur das erforderliche Minimum an PII/Findaten (umgekehrtes Pyramidenmodell), die Details liegen in Anreicherungen.
Signatur/Hash kritischer Attribute, Integritätskontrolle.
In-Flight- und At-Rest-Verschlüsselung, Aufteilung der Rechte nach Thema/Consumer (IAM/ACL).
Retentionsrichtlinien und das Recht auf Vergessenwerden: Für jeden Bereich klar definiert.

Leistung und Nachhaltigkeit

Backpressure: Verbraucher haben Wettbewerbsbeschränkungen, der Broker hat Quoten/Grenzen.
Batch-Verarbeitung und Kompression: Gruppieren Sie Datensätze, um den Overhead zu reduzieren.
Retrays mit Jitter und DLQ statt endloser Versuche.
Rebalance-Resilienz: Offsets transaktional/extern speichern, Kaltstart mit Schnappschüssen beschleunigen.

Typische Ereignisvorlagen

Kern der Zahlungen

`payment. initiated. v1` → `payment. authorized. v1` → `payment. captured. v1` → `payment. settled. v1`

Ablehnungen: "Zahlung. declined. v1`, `payment. refunded. v1`

Beteiligungen: „payment _ id“

SLA: Kernlag ≤ 2c p95 Die Idempotenz der Verbraucher ist obligatorisch.

CUS/Verifizierungen

`kyc. started. v1` → `kyc. document. received. v1` → `kyc. approved. v1`/`kyc. rejected. v1`

PII - minimal; Dokumentdetails - in 'kyc. enriched. v1 'mit eingeschränktem Zugang.

Audit/Sicherheit

`audit. recorded. v1 'mit den Attributen' actor', 'subject', 'action', 'occurred _ at', 'trace _ id'.
Kontinuierliche Retention/Archivierung; Erhöhte Integrität (WORM-Speicher).

Anti-Pattern

Fat Event: überlastete payload's ohne Not, PII Lecks.
Hidden RPC durch Ereignisse: Warten auf synchrone Antworten „Hier und Jetzt“.
Rohe CDCs nach außen: Enge Anbindung an das OBD-Schema.
Keine Idempotenz bei Verbrauchern: Takes führen zu doppelten Nebenwirkungen.
Eine gemeinsame Spitze „für alles“: Interessenkonflikte, problematische Ordnung, komplexe Evolution.

Schrittweise EDC-Implementierung

1. Domain Mapping: Markieren Sie wichtige Aggregate und Lebenszyklen.
2. Ereigniskatalog: Titel, Bedeutungen, Invarianten, Pflichtfelder.
3. Schemas und Registrierung: Wählen Sie ein Format aus und aktivieren Sie Kompatibilitätsregeln.
4. Outbox/CDC: Definieren Sie für jeden Produzenten einen Mechanismus zur Veröffentlichung von Fakten.
5. Partitionierung: Wählen Sie die Schlüssel aus und bewerten Sie Hot Keys/Redislocation.
6. Idempotenz: Deduplizierungsmuster + Transaktionalität der Verbraucher.
7. Projektionen: Identifizieren Sie materialisierte Modelle und Update-SLAs.
8. Observability: Tracing, Lags, DLQ, Alerts.
9. Sicherheit/PII: Datenklassifizierung, Verschlüsselung, ACL.
10. Hyde zur Evolution: Versionspolitik, Deprecate, Dual-Write für Migrationen.

Checkliste der Produktion

Jedes Ereignis hat 'event _ id', 'trace _ id', 'occurred _ at', 'partition _ key'.
Schemes in the register, compatibility checks included.
Die Idempotenz der Verbraucher wurde umgesetzt und getestet.
DLQ/Parking Lot und Alerts für Publishing-/Konsumfehler konfiguriert.
Projektionen werden aus dem Protokoll (replay) mit akzeptabler Zeit neu erstellt.
Eingeschränkter Zugang zum PII; minimale payload's im Kernel.
SLAs nach Lags/Lieferung werden gemessen und sind auf Dashboards sichtbar.
Es gibt einen Plan für die Migration von Ereignisversionen und Deprecate-Fenstern.

FAQ

Wie unterscheidet sich EDC von „just the bus“?
Der Kern ist nicht nur der Makler, sondern auch der Ereignisvertrag, die Regeln der Ordnung/Idempotenz, die Evolutionsprozesse und die Beobachtbarkeit.

Kann man nur auf CDC bauen?
CDC eignet sich für Integrationen/Migrationen, aber Domänenereignisse drücken die Bedeutung klarer aus und erleben DB-Veränderungen stabiler.

Was ist mit der Kohärenz?
Wir übernehmen die eventuelle Consistency und gestalten die UX/Prozesse dafür (Update Indikatoren, Retrays, Vergütungen).

Wann wird exactly-once benötigt?
Selten: Wenn eine Verdoppelung streng unzulässig ist und nicht kompensiert werden kann. Häufiger reicht eine At-Least-Once + Idempotenz.

Summe

Der Event-Driven Core verwandelt den Business Facts Flow in ein solides Systemfundament. Klare Ereignisverträge, Lieferdisziplin und Beobachtbarkeit geben Skalierbarkeit, Nachhaltigkeit und Evolutionsgeschwindigkeit - ohne fragile synchrone Verknüpfungen und „Sturm“ -Regressionen bei Veränderungen.