OrderCreated enthält Event-ID, Zeit, Schema-Version, Order-ID und fachlich notwendige Daten. Der Vertrag vermeidet interne Tabellenstrukturen.
CommerceOne Architekturgeschichte
Ein Ereignis durch die Plattform verfolgen
Schema, Partitionierung, Consumer Groups, Retry, DLQ und Observability.
0 % geöffnet
Event Flow verständlich gelesen
Ein Event ist mit einem eingeschriebenen Brief vergleichbar: Der Producer schreibt eine Nachricht, Kafka ordnet sie einem Topic und einer Partition zu, und Consumer lesen sie in ihrer eigenen Geschwindigkeit. Offsets markieren, bis wohin ein Consumer gekommen ist.
Alltagstaugliche Ablaufbeschreibung
Dieser Abschnitt beschreibt den Ablauf ohne unnötige Fachsprache. Er dient als Brücke zwischen dem sichtbaren Ergebnis und der technischen Umsetzung.
- Producer erstellt Event
- Schema wird geprüft
- Broker speichert Event
- Partition bestimmt Reihenfolge
- Consumer Group verteilt Arbeit
- Consumer bestätigt Offset
- Telemetrie misst Lag und Fehler.
Fachlicher Ablauf
Ein fachliches Ereignis informiert andere Bereiche darüber, dass sich etwas Relevantes geändert hat. Der sendende Bereich bleibt verantwortlich für seine Aussage; empfangende Bereiche entscheiden selbst, wie sie darauf reagieren.
- Fachliches Ziel: Der Ablauf liefert ein fachlich eindeutiges und für Benutzer beziehungsweise Betrieb nachvollziehbares Ergebnis.
- Verantwortung: Jeder beteiligte Bereich entscheidet nur innerhalb seiner eigenen fachlichen Zuständigkeit.
- Sichtbares Ergebnis: Order, Inventory, Payment und Notification können unabhängig reagieren, ohne eng gekoppelte synchrone Aufrufketten.
Technischer Ablauf
Der Producer schreibt ein Event in ein Topic. Partitionierung bestimmt Reihenfolge und Parallelität, Consumer Groups verteilen Arbeit, Offsets dokumentieren den Verarbeitungsstand. Retry, Idempotenz und Dead Letter Queue schützen vor Doppelwirkung und dauerhaft fehlerhaften Nachrichten.
- Daten und Schnittstellen: Daten werden an jeder Grenze validiert und nur über definierte APIs, Ports oder Events weitergegeben.
- Fehlerbehandlung: Fehler werden dort behandelt, wo ausreichender Kontext und Verantwortung vorhanden sind; Wiederholungen müssen sicher und nachvollziehbar bleiben.
- Technischer Nachweis: Geprüft werden Producer-Erfolg, Topic/Partition, Consumer Lag, Offset-Fortschritt, Retry-Zahl und DLQ-Einträge.
Zusammenspiel: Der fachliche Ablauf erklärt, warum etwas geschieht und welches Ergebnis zählt. Der technische Ablauf erklärt, wie dieses Ergebnis zuverlässig, sicher und beobachtbar umgesetzt wird.
1. Event Contract wird versioniert
2. Partition-Key erhält Reihenfolge
Order-ID als Key hält Ereignisse derselben Bestellung in einer Partition. Globale Reihenfolge wird nicht behauptet.
3. Consumer verarbeitet idempotent
Consumer speichert verarbeitete Event-IDs oder nutzt eine fachlich eindeutige Operation. Erst danach wird der Offset bestätigt.
4. Fehler werden klassifiziert
Temporäre Infrastrukturfehler erhalten Backoff; ungültige fachliche Nachrichten gehen mit Kontext in eine DLQ.
5. Trace-Kontext bleibt erhalten
Correlation- und Trace-Informationen werden als Header weitergegeben. So lässt sich der Weg über synchrone und asynchrone Grenzen nachvollziehen.
Architekturentscheidung
Der Event-Flow wird als eigener Betriebsvertrag behandelt: Schema, Schlüssel, Zustellverhalten, Retry, DLQ und Telemetrie sind Teil des Designs.
Lernkontrolle
Wann darf ein Kafka-Consumer seinen Offset sicher bestätigen?
Antwort selbst formulieren
Weiterlernen
Öffne markierte Fachbegriffe direkt im Text oder untersuche ihre Beziehungen im Knowledge Graph.