Event-Sourcing ist ein Architekturprinzip, bei dem der Zustand eines Systems nicht in Form aktueller Daten gespeichert wird, sondern als Abfolge von Ereignissen. Jede Änderung wird als unveränderliches Event protokolliert, sodass die gesamte Historie eines Systems jederzeit nachvollziehbar bleibt.

Ein Bibliothekssystem könnte folgende Events haben:

• BookRegistered → Ein neues Buch wird registriert.
• BookBorrowed → Ein Leser leiht ein Buch aus.
• BookReturned → Ein Buch wird zurückgegeben.
• BookDamaged → Ein Buch wird als beschädigt markiert.
• BookRepaired → Ein Buch wurde repariert.
• BookRemoved → Ein Buch wird entfernt (Verlust oder irreparabel).

Der Zustand eines Buches ergibt sich durch das Anwenden aller relevanten Events in chronologischer Reihenfolge.

• Nachvollziehbarkeit & Historisierung: Jede Änderung bleibt erhalten.
• Reproduzierbarkeit: Der Zustand kann jederzeit rekonstruiert werden.
• Asynchrone Verarbeitung: Events können von verschiedenen Systemen verarbeitet werden.
• Auditierbarkeit: Vollständige Nachverfolgbarkeit aller Systemänderungen.
• Zukunftssicherheit: Alle Änderungen des Systems sind dokumentiert und zugänglich, auch für zukünftige Anforderungen.

• Komplexität: Aufwendiger als klassische CRUD-Ansätze.
• Speicherbedarf: Die Anzahl der Events steigt im Laufe der Zeit.
• Fehlerkorrektur: Fehlerhafte Events müssen durch Korrektur-Events oder spezielle Mechanismen ausgeglichen werden.
• Performance bei Rekonstruktion: Die Berechnung des aktuellen Zustands durch Replaying aller Events kann ineffizient sein.
  Lösung: Verwendung von Projektionen und Snapshots.

CQRS ist ein Architekturprinzip, bei dem Lese- und Schreiboperationen strikt voneinander getrennt werden. Anstatt ein gemeinsames Datenmodell für alles zu verwenden – wie bei klassischen CRUD-Ansätzen – definiert CQRS zwei unterschiedliche Modelle:

Command Model

• Verarbeitet Befehle
• Erzeugt Events
• Ändert den Zustand
• Beispiel: „Buch registrieren“

Query Model

• Stellt Daten zur Verfügung
• Optimiert für effiziente Lesezugriffe
• Beispiel: „Buch abrufen“

Diese Trennung ermöglicht eine bessere Skalierbarkeit, gezielte Optimierung beider Seiten und fördert klare Verantwortlichkeiten im Code.

• Skalierbarkeit: Lese- und Schreiboperationen können getrennt optimiert und skaliert werden.
• Optimierte Modelle: Die Datenhaltung kann je nach Aufgabe optimiert werden.* Im Kontext von Event-Sourcing bedeutet das: Events fungieren als Schreibmodell, während Projektionen als Lesemodelle dienen können.
• Technologische Flexibilität: Verschiedene Technologien für Lese- und Schreibseiten möglich (z. B. SQL für Schreiboperationen, NoSQL oder In-Memory für Leseoperationen).

• Erhöhte Komplexität: Daten müssen zwischen den Modellen synchronisiert werden.
• Ungewohnte Architektur: Nicht der (gelernte) klassische CRUD-Ansatz.

Aggregates stammen aus Domain-Driven Design (DDD) und spielen eine zentrale Rolle in Event-Sourcing und CQRS:

• In Event-Sourcing können Aggregate Events erzeugen und rekonstruieren ihren Zustand durch Replaying dieser Events.
• In CQRS sind Aggregates für die Verarbeitung von Commands zuständig, indem sie Geschäftslogik anwenden, den Zustand des Systems ändern und entsprechende Events erzeugen.

Projektionen sind Lese-Modelle, die aus Events aufgebaut werden. Sie ermöglichen schnelle Abfragen, indem sie den aktuellen Zustand in einer optimierten Form speichern.

• Funktionieren wie materialisierte Ansichten
• Können in separaten, für das Lesen optimierten Datenbanken gespeichert werden (SQL, NoSQL, Suchdatenbank, In-Memory)
• Lassen sich jederzeit durch Replaying der Events neu generieren

Da die Rekonstruktion aller Events teuer sein kann, werden Snapshots genutzt. Sie speichern den Zustand eines Aggregats zu einem bestimmten Zeitpunkt, sodass nur neuere Events rekonstruiert werden müssen.

Abgrenzung zwischen Projektionen und Snapshots

Obwohl beide Konzepte aus Events abgeleitet werden, dienen sie unterschiedlichen Zwecken und kommen in verschiedenen Teilen des Systems zum Einsatz.

Projektionen

• Für die Lese-Seite (Queries)
• Optimiert für schnelle Abfragen
• Separate Speicherung (z. B. SQL, NoSQL)
• Repräsentieren den aktuellen Zustand eines Objekts

Snapshots

• Für die Schreib-Seite (Aggregates)
• Dienen der Ladeoptimierung von Aggregates
• Werden im selben Speicher wie Events abgelegt
• Repräsentieren den Zustand eines Aggregats zu einem bestimmten Zeitpunkt

Event-Sourcing und CQRS sind leistungsstarke Architekturprinzipien, die besonders bei komplexen Systemen ihre Stärken ausspielen. Sie bieten hohe Nachvollziehbarkeit, Skalierbarkeit und Flexibilität, gehen jedoch mit einer höheren Komplexität einher als klassische CRUD-Ansätze. Während CRUD direkt den aktuellen Zustand speichert, setzen Event-Sourcing und CQRS auf eine entkoppelte, historisierte Sicht auf Systemzustände – was völlig neue Möglichkeiten und Herausforderungen mit sich bringt.

Wer Systeme entwickeln möchte, die auditierbar, skalierbar und auf verteilte Verarbeitung ausgelegt sind, sollte sich mit diesen Konzepten intensiv auseinandersetzen.

• Systeme mit hoher Änderungsnachverfolgbarkeit oder Audit-Anforderungen
• Wenn viele Lesezugriffe von wenigen Schreibzugriffen entkoppelt werden sollen
• In verteilten Architekturen mit asynchroner Verarbeitung
• Bei komplexen Domänenmodellen (Aggregates, Eventflüsse)
• Wenn zukünftige fachliche Anforderungen auch rückwirkend beantwortet werden sollen

• Bei einfache CRUD-Anwendungen ohne Historisierung oder Audit
• Projekte mit Fokus auf schnelle Umsetzung und wenig Aufwand

• Höhere Komplexität: In der Umsetzung und beim Onboarding neuer Entwickler:innen
• Fehlerbehandlung: Events sind unveränderlich → kompensierende Events notwendig
• Event-Versionierung: Änderungen am Event-Schema erfordern durchdachte Strategien
• Performance beim Replaying: Snapshots reduzieren das teure Replaying
• Daten-Synchronisation bei CQRS: Query-Modelle müssen zuverlässig aktualisiert werden

• NestJS mit Prisma: byteleaf/es-cqrs-sample
• NestJS mit Ocoda: byteleaf/es-cqrs-sample (Feature Branch)

* Auch außerhalb von Event-Sourcing möglich – z. B. durch normalisierte Datenhaltung für Schreiboperationen und denormalisierte Datenhaltung für Leseoperationen.