Event Stream
Event Streams verbinden dauerhafte Historie mit unabhängigen Leserpositionen.
- PartitionDefiniert Reihenfolge und Einheit paralleler Verarbeitung.
- OffsetMarkiert den Lesefortschritt einer Konsumentengruppe.
- RetentionBegrenzt Zeitraum und Umfang möglicher Wiederholung.
Einordnung
Warum das wichtig ist
Wiederlesbarkeit ist nur so stark wie Retention, Schemaevolution und Replay-Sicherheit.
Die Analyseplattform ist hypothetisch; aktuell nutzt der Shop sieben Module und gemeinsame Infrastruktur.
Streamentscheidungen
Der heutige Shop bleibt ein modularer Monolith mit sieben Modulen. Für eine hypothetische Analyseplattform werden Bestellereignisse nach Bestell-ID partitioniert und 90 Tage aufbewahrt. Versand liest live mit eigener Gruppe; Analyse baut eine Projektion ab ihrem Offset auf. Das Team löscht die Analyseprojektion, spielt die verfügbare Historie erneut ein und prüft Reihenfolge pro Bestellung, Schemafähigkeit und idempotente Verarbeitung. Es dokumentiert ausdrücklich, welche Sicht nach Ablauf der Retention nur aus einem Snapshot wiederherstellbar wäre.
So liest du das Bild
- Partition Bestell-ID als Schlüssel
- Offset Nach Wirkung speichern
- Retention Snapshot für ältere Zustände
| Vergleich | Entscheidung | Gewinn | Folge |
|---|---|---|---|
| Eine Partition | Globale Reihenfolge | Einfacher Offset | Begrenzter Durchsatz |
| Schlüsselpartitionen | Parallelität | Reihenfolge je Schlüssel | Keine globale Ordnung |
| Zeitliche Retention | Begrenzter Speicher | Replay im Zeitraum | Ältere Basis braucht Snapshot |
Nutzen & Grenzen
Hilft, wenn
- Mehrere Leser brauchen dieselbe Ereignishistorie.
- Projektionen sollen nach Fehlern oder Codeänderungen neu aufgebaut werden.
- Reihenfolge pro Fachschlüssel genügt.
Grenzen
- Retention kann ältere Ereignisse vor einem vollständigen Replay entfernen.
- Mehr Partitionen erhöhen Parallelität, beseitigen aber globale Reihenfolge.
- Replay kann externe Wirkungen erneut auslösen und braucht getrennte Schutzregeln.
In der Praxis
- Lies BestellungBestätigt mit getrennten Offsets für Versand und Analyse. Notiere, wie lange ein später gestarteter Leser die Ereignishistorie noch abfragen kann.
- Setze einen Leser zurück auf einen früheren Offset und vergleiche die neu berechnete Projektion mit ihrem Kontrollwert. Plane Duplikatbehandlung ein.
- Bewerte Partitionsschlüssel, Reihenfolge und Aufbewahrungsdauer für Shopereignisse. Nenne, welche Abfrage bei zu kurzem Retentionsfenster unmöglich wird.
Ausführliche Erklärung lesen
Publisher hängen unveränderliche Ereignisse an eine Partition an. Ein Offset bezeichnet ihre Lage; Konsumentengruppen speichern unabhängig, bis wohin sie verarbeitet haben.
Partitionierung bestimmt Parallelität und Ordnungsgrenze. Replay ermöglicht neue Projektionen und Reparaturen, setzt aber verfügbare Historie, kompatible Schemas und idempotente Wirkungen voraus.
Publish-Subscribe erklärt Fan-out an Abonnenten. Event Sourcing nutzt Ereignisse als maßgeblichen Fachzustand; ein Stream allein macht diese Modellentscheidung nicht.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Wo gilt typischerweise Reihenfolge?
Lösung mit Begründung ansehen
Innerhalb einer Partition.
AnwendenAuf eine neue Lage übertragen
Wie baut Analyse ihre Sicht neu auf?
Lösung mit Begründung ansehen
Aus Snapshot oder Anfangsoffset plus allen innerhalb der Retention verfügbaren Ereignissen.
BewertenEine Alternative abwägen
Warum ist ein Stream nicht automatisch Event Sourcing?
Lösung mit Begründung ansehen
Weil die Ereignisse nicht zwingend der maßgebliche Fachzustand sind.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.