Event-driven Architecture & Streaming-Plattformen

# Event-driven Architecture und Streaming-Plattformen

2017 stellte ein batch-orientierter Händler fest, dass sein „Fraud-Detection-System“ Betrug im Schnitt neun Stunden nach der Buchung der Transaktion erkannte. Das Modell war exzellent. Das Problem war die PipelinePipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Vollständige Definition ansehen →: Die Fraud-Signale lagen in einem nächtlichen ETLETLETL (Extract, Transform, Load) is a data integration process that pulls data from sources, reshapes it into a consistent format, and writes it into a target system.Vollständige Definition ansehen →-Job und warteten auf den Lauf um 2 Uhr morgens. Als der Alert ausgelöst wurde, war die Ware verschickt und die Karte ausgereizt. Die Lösung war kein besseres Modell. Es war eine andere *Form* der Datenbewegung, eine, in der die Transaktion ihre eigene Existenz in dem Moment ankündigt, in dem sie passiert, und beliebig viele Systeme in Millisekunden reagieren kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen.

Dieser Wechsel, von der Frage an Systeme „was ist der aktuelle Stand?“ hin dazu, Systeme *ankündigen zu lassen, dass sich etwas geändert hat*, ist der Kern von Event-driven Architecture. Als CDO verantworten Sie bereits die Datenstrategie und die Governance darum herum. Was die meisten Data Leader unterschätzen: Die *Architektur der Datenbewegung* ist ein strategischer Hebel, kein Installationsdetail. Machen Sie es falsch, und jede Echtzeit-Ambition Ihres CEO, Personalisierung, Dynamic PricingDynamic PricingAutomatically adjusting prices in real time based on demand, competition or user behaviour to optimise revenue, margin or conversion.Vollständige Definition ansehen →, operative KI, stirbt in einem nächtlichen Batch-Fenster.

Was ein Event tatsächlich ist (und warum es alles verändert)

Ein Event ist ein unveränderlicher Fakt über etwas, das passiert ist, versehen mit einem Zeitstempel. OrderPlaced. PaymentFailed. SensorReadingExceededThreshold. CustomerLoggedIn. Beachten Sie die Vergangenheitsform, das ist kein Zufall. Ein Event ist kein Command („belaste diese Karte“) und keine Query („wie hoch ist der Saldo?“). Es ist ein Nachweis, dass *sich die Welt bewegt hat*, und es lässt sich nicht rückgängig machen.

Diese Unterscheidung wiegt schwerer, als sie klingt. In Ihrer traditionellen Welt ist die Source of Truth eine Tabelle, ein Snapshot des *aktuellen* Zustands. Die Adresse eines Kunden ist das, was die Zeile heute sagt. In einer event-driven Welt wird die Source of Truth zum *Log all dessen, was jemals passiert ist*, und der aktuelle Zustand ist nur eine Projektion, die Sie aus diesem Log berechnen. Die Adresse des Kunden ist das Ergebnis des Replays jedes AddressChanged-Events.

Das ist der Wechsel des mentalen Modells, den die meisten Führungskräfte übersehen, deshalb mache ich ihn an den praktischen Konsequenzen konkret:

• Zustand wird rekonstruierbar. Wenn ein nachgelagertes System seine Daten beschädigt, spielen Sie das Event-Log erneut ab und bauen es neu auf. Batch-Pipelines kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen das nicht; die Quellzeilen wurden bereits überschrieben.
• Neue Consumer können spät dazukommen und bekommen trotzdem Historie. Ein Team baut sechs Monate nach dem Launch einen ML Feature StoreML Feature StoreA centralised repository managing ML features, ensuring consistency between training and serving environments.Vollständige Definition ansehen → auf und spielt zwei Jahre Events zurück, um zu backfillen. Kein Data-Engineering-Ticket, keine Last auf dem Quellsystem.
• Zeit wird zum First-Class Citizen. Sie kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen fragen „was wussten wir um 15:14 Uhr?“, entscheidend für Audit, Model-Debugging und regulatorische Rekonstruktion.

Das Fraud-Problem des Händlers bestand im Kern darin, dass ererThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → Transaktionen als *später abzufragenden Zustand* behandelte statt als *Events, auf die jetzt reagiert wird*.

Das Event als Contract

Hier müssen sich die Governance-Instinkte des CDO bis in die Architektur erstrecken. Ein Event ist ein veröffentlichter Contract zwischen dem, der es produziert, und allen, die es konsumieren. Das SchemaSchemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.Vollständige Definition ansehen → von OrderPlaced, seine Felder, Typen und Bedeutung, wird zu einer unternehmensweit geteilten APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Vollständige Definition ansehen →. Ändern Sie es unbedacht, und Sie zerstören Systeme, von denen Sie nie gehört haben.

Deshalb betreiben reife Streaming-Organisationen eine Schema Registry mit erzwungenen Kompatibilitätsregeln. Sie dürfen ein Feld nicht umbenennen, nur weil es für Ihr Team gerade praktisch war. Events sind strategische Assets, die genauso governed werden wie die Data Products in Ihrem Monetarisierungsportfolio: versioniert, mit klarem Owner, dokumentiert und per Policy rückwärtskompatibel.

Warum die Entkopplung von Producern und Consumern der eigentliche Gewinn ist

Der technische Vorteil, den alle nennen, ist „Skalierung“. Das stimmt, greift aber zu kurz. Der tiefere Gewinn ist die *organisatorische Entkopplung*, und das ist ein CDO-Thema, denn Ihr Engpass ist selten Rechenleistung. Es ist die Koordination zwischen Teams.

In einer request-getriebenen Welt ist Integration Punkt-zu-Punkt. Das Bestellsystem ruft das Inventarsystem auf, das ruft das Loyalty-System auf, das ruft das Analytics-System auf. Jeder neue Consumer bedeutet eine neue Integration, eine neue Abhängigkeit, ein neues Meeting. Mit *N* Systemen marschieren Sie auf *N²* Verbindungen zu, und jede einzelne ist eine Stelle, an der Ihre Architektur blockieren kann. Das ist die „Integrations-Spaghetti“, die still und leise 40 % Ihrer Engineering-Kapazität frisst.

Event-driven Architecture dreht das um. Der Producer veröffentlicht OrderPlaced in einem Stream und weiß nicht und interessiert sich nicht dafür, wer es konsumiert. Das Inventar-Team subscribed. Später subscribed das Loyalty-Team. Noch später subscribed ein Data-Science-Team, um ein Churn-Feature zu bauen, ohne je mit dem Bestellteam zu sprechen. Die Aufgabe des Producers endete, als ererThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → den Fakt veröffentlicht hat.

Producer  →  [ OrderPlaced topic ]  →  Inventory service
                                    →  Loyalty service
                                    →  Fraud scoring
                                    →  Analytics / feature store

Der organisatorische Payoff: Teams liefern ohne teamübergreifende Verhandlung. Ihre Datenplattform hört auf, eine Warteschlange von Integrationsanfragen zu sein, und wird zu einem Marktplatz, auf dem Teams nach eigenem Zeitplan publishen und subscriben. Für einen CDO, der die Datennutzung in einem Unternehmen skalieren will, das dem zentralen Team entwächst, ist das das einzige Modell, das funktioniert. Zentralisierte Punkt-zu-Punkt-Integration skaliert ab einer bestimmten Organisationsgröße nicht mehr, sie verwandelt nur Ihre besten Engineers in Vollzeit-Integrationsmakler.

Die Trade-offs, die Sie verantworten und nicht delegieren

Entkopplung ist nicht umsonst, und die Kosten sind genau die, über die ein CDO entscheiden muss, weil sie Teamgrenzen überschreiten:

• Eventual Consistency. Consumer verarbeiten in ihrem eigenen Tempo. Für ein paar hundert Millisekunden, manchmal Sekunden, widersprechen sich Inventarbestand und Bestellzahl. Ihre Business-Partner müssen verstehen, dass „Echtzeit“ heißt „irgendwann, schnell und asynchron“, nicht „überall sofort konsistent“. Das ist ein Business-Gespräch, kein technisches.
• Debugging wird verteilt. Wenn etwas schiefgeht, verteilt sich die Geschichte über ein Dutzend unabhängig laufender Consumer. Sie brauchen Distributed Tracing und starke Observability *ab Tag eins*, nicht nachträglich angeschraubt nach dem ersten Incident.
• Reihenfolge und Duplikate. Streaming-Plattformen garantieren typischerweise *At-least-once*-Zustellung, das heißt, ein Consumer sieht dasselbe Event möglicherweise zweimal. Jeder Consumer muss idempotent sein, dasselbe Event zweimal zu verarbeiten führt zum selben Ergebnis. Das ist eine Design-Disziplin, die Sie per Policy vorschreiben müssen, denn ein einziger nicht-idempotenter Consumer, der einen Kunden doppelt belastet, wird *Ihre* Schlagzeile.

Die Plattformen: Kafka vs. Cloud Pub/Sub und wie Sie wählen

Sie müssen keinen Broker konfigurieren. Sie müssen die Plattform-*Entscheidung* richtig treffen, denn es ist eine Festlegung für fünf bis zehn Jahre mit realen Kosten- und Lock-in-Folgen.

Apache Kafka (und seine Managed-Varianten, Confluent Cloud, AWS MSK) ist ein *verteiltes, dauerhaftes Log*. Events werden in Topics geschrieben, für Parallelität partitioniert und, entscheidend, *aufbewahrt*. Kafka behält Events Tage, Wochen oder für immer. Genau das ermöglicht Replay, Backfill und die Behandlung des Logs als Source of Truth. Consumer verfolgen ihre eigene Position (den „Offset“) und kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen zurückspulen. Kafka ist der richtige Default, wenn das Event-Log ein dauerhaftes Asset sein soll, wenn Sie sehr hohen Durchsatz brauchen und wenn Replay zentral für Ihre Use Cases ist (Feature Stores, Event Sourcing, Audit).

Cloud Pub/Sub (Google Pub/Sub, AWS SNS/SQS, Azure Service Bus) ist ein *Messaging-Service*. Sein mentales Modell lautet „liefere diese Nachricht an die Subscriber und mach weiter“. Die Retention ist kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →ürzer und Replay ist eingeschränkter. Dafür ist der Betrieb dramatisch einfacher, vollständig serverless, nahezu kein Ops-Overhead, elastische Skalierung, ohne dass Sie über Partitionen nachdenken. Es ist die richtige Wahl, wenn Sie event-driven Entkopplung wollen, *ohne* eine Plattform zu betreiben, und wenn das Replay tiefer Historie keine Kernanforderung ist.

Hier das Entscheidungs-Framework, das ich auf eine Folie packen würde:

| Wenn Ihre Priorität ist… | Tendieren Sie zu… |

|---|---|

| Replay, Backfill, Log als Source of Truth | Kafka |

| Sehr hoher Dauerdurchsatz, Stream Processing | Kafka |

| Minimale Ops, serverless, schnelle Time-to-Value | Cloud Pub/Sub |

| Einfaches Fan-out von Benachrichtigungen zwischen Services | Cloud Pub/Sub |

| Tiefes Ökosystem (Connectoren, Stream SQLSQLSales Qualified Lead: a prospect the sales team has validated as ready for direct outreach and a proposal, having passed clear qualification criteria.Vollständige Definition ansehen →, Tooling) | Kafka / Confluent |

Der Fehler, den ich immer wieder sehe: Teams führen Kafka wegen des Prestiges ein und bauen dann ein Jahr lang operative Muskeln auf, die sie für ein in Wahrheit reines Benachrichtigungsproblem nicht gebraucht hätten. Wählen Sie die Plattform nach dem *Bedarf des Use Case an Historie und Durchsatz*, nicht nach Résumé-driven Development.

Eine Config-Idee, die es wert ist, verinnerlicht zu werden

Sie schreiben das nicht, aber Sie sollten erkennen, worum es geht, wenn Ihre Architekten darüber diskutieren. In Kafka setzt die Partitionszahl eines Topics die Obergrenze für parallelen Konsum:

partitions = 12       # up to 12 consumers process this topic in parallel
retention.ms = 604800000   # keep every event for 7 days for replay

Das darin steckende Urteil: Partitionen lassen sich später nur schwer erhöhen, ohne Ordering-Garantien zu brechen. Zu knapp dimensioniert drosseln Sie den Durchsatz; zu großzügig verschwenden Sie Ressourcen und verkomplizieren das Rebalancing. Wenn Ihr Team eine Entscheidung zur Partitionsstrategie will, bittet es Sie in Wahrheit, den Trade-off zwischen kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →ünftiger Skalierung und heutiger Einfachheit zu bepreisen. Das ist eine CDO-Entscheidung, nicht die eines Junior Engineers.

Wo ein CDO das am Montagmorgen tatsächlich anwendet

Frameworks sind ohne Anwendung wertlos. Hier verdient Event-driven Architecture ihr Geld, und so entscheiden Sie, *ob sie überhaupt gerechtfertigt ist*.

1. Operative Echtzeit-Analytics und KI. Ihr Fraud-Beispiel, Dynamic PricingDynamic PricingAutomatically adjusting prices in real time based on demand, competition or user behaviour to optimise revenue, margin or conversion.Vollständige Definition ansehen →, Recommendation Engines, Umverteilung von Beständen, Predictive Maintenance. Jede Entscheidung, deren Wert *mit der Zeit verfällt*, ist ein Kandidat. Der Test: Schlägt eine in 200 Millisekunden getroffene Entscheidung dieselbe Entscheidung nach sechs Stunden? Wenn ja, lässt Batch Geld liegen.

2. Den Feature Store füttern. Das ist die Anwendung mit dem größten Hebel und der geringsten Wertschätzung. Wenn Ihre ML-Grundlagen stehen, ist der nächste Reifesprung *frische Features*. Ein Modell, das auf 24 Stunden alten Features scored, rät. Events in den Feature StoreFeature StoreA centralised repository managing ML features, ensuring consistency between training and serving environments.Vollständige Definition ansehen → zu streamen heißt, dass dasselbe Event, das den Betrieb steuert, auch das Modell steuert, und das eliminiert den berüchtigten Training-Serving-Skew, bei dem Ihre Batch-PipelinePipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Vollständige Definition ansehen → und Ihre Live-PipelinePipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Vollständige Definition ansehen → Features unterschiedlich berechnen.

3. Change Data Capture (CDC) als Einstiegsrampe. Sie müssen nicht das Meer auskochen. CDC-Tools (Debezium ist das übliche) lesen das Transaktionslog Ihrer bestehenden Datenbanken und *emittieren jede Zeilenänderung als Event*, ohne die Quellanwendung anzufassen. Das ist der pragmatische Einstieg: Sie bekommen einen Event Stream aus einem Legacy-System, das kein Konzept von Events kennt, und kaufen sich Zeit, um schrittweise zu modernisieren. So starten die meisten Unternehmen tatsächlich.

4. Den Monolithen aufbrechen ohne Rewrite. Wenn Sie eine neue Fähigkeit brauchen, die sonst die Änderung eines fragilen Kernsystems erfordern würde, subscriben Sie stattdessen dessen Events, statt seinen Code anzufassen. Event-driven Architecture ist oft der *am wenigsten invasive* Weg, Wert auf Systemen aufzubauen, deren Ersatz Sie sich nicht leisten kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen.

Die Anti-Patterns, die Sie teuer zu stehen kommen

Sagen Sie Nein zu Streaming, wenn:

• Die Daten von Natur aus Batch sind. Monatlicher Financial Close, Quartalsreporting, wöchentliches Model Retraining, das in Streaming zu pressen erzeugt Kosten und Komplexität ohne jeden Latenzvorteil. Nicht alles muss Echtzeit sein; „Echtzeit überall“ ist ein Architektur-Geruch.
• Ihnen die operative Reife fehlt. Streaming-Plattformen verlangen Observability, On-Call-Disziplin und Strenge bei Idempotenz. Kafka einzuführen, bevor Sie das haben, erzeugt ein fragiles System, das still versagt und das Vertrauen in Daten untergräbt, das eine Asset, dessen Verlust Sie sich nicht leisten kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen.
• Es jemals nur einen einzigen Consumer geben wird. Der ganze Wert liegt in vielen unabhängigen Consumern. Ein Producer, ein Consumer, für immer? Eine direkte Integration ist einfacher, und die sollten Sie nutzen.

Die strategische Einordnung für Ihre Kollegen im Vorstand: Event-driven Architecture ist eine Investition in *Optionalität*. Sie zahlen jetzt einen Komplexitätsaufschlag, damit kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →ünftige Use Cases billig hinzuzufügen sind. Das ist gerechtfertigt, wenn Sie eine Roadmap mit Echtzeit- und KI-Ambitionen haben. Es ist Over-Engineering, wenn nicht.

Key Takeaways

1. Behandeln Sie Events als governed Contracts, nicht als Nachrichten. Erweitern Sie Ihre bestehende Governance-Disziplin in eine SchemaSchemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.Vollständige Definition ansehen → Registry mit erzwungener Rückwärtskompatibilität. Eine breaking SchemaSchemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.Vollständige Definition ansehen →-Änderung ist eine breaking APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Vollständige Definition ansehen →-Änderung, und der Blast Radius liegt bei Ihnen.

2. Kaufen Sie Entkopplung, nicht nur Geschwindigkeit. Der strategische Gewinn ist, dass Teams ohne teamübergreifende Verhandlung publishen und subscriben. Wenn Ihre Datenplattform eine Warteschlange von Integrationsanfragen ist, ist Event-driven Architecture der Weg, den Engpass aufzulösen, während die Organisation wächst.

3. Wählen Sie die Plattform nach ihrem Bedarf an Historie. Default Kafka, wenn Replay, Backfill und Log-als-Source-of-Truth zählen; Default Cloud Pub/Sub, wenn Sie event-driven Entkopplung mit nahezu null Betriebsaufwand wollen. Lehnen Sie Résumé-driven Kafka-Einführung für Probleme in Benachrichtigungsform ab.

4. Starten Sie mit CDC, nicht mit einem Rewrite. Emittieren Sie Events aus Ihren bestehenden Datenbanken via Change Data Capture, um aus Legacy-Systemen Wert zu ziehen, ohne deren Code anzufassen, und modernisieren Sie dann inkrementell.

5. Schreiben Sie Idempotenz und Observability ab Tag eins per Policy vor. At-least-once-Zustellung heißt, jeder Consumer muss Duplikate sicher handhaben, und verteiltes Debugging verlangt Tracing vor Ihrem ersten Incident, nicht danach.