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 Durchschnitt neun Stunden nach der Autorisierung der Transaktion erkannte. Das Modell war ausgezeichnet. Das Problem war die PipelinePipelineAlle aktiven Verkaufschancen über die Phasen des Vertriebsprozesses hinweg, zusammen mit ihrem gesamten potenziellen Wert und ihrer Abschlusswahrscheinlichkeit.Vollständige Definition ansehen →: Fraud-Signale lagen in einem nächtlichen ETLETLETL (Extract, Transform, Load) ist ein Datenintegrationsprozess, der Daten aus Quellsystemen extrahiert, in ein konsistentes Format bringt und in ein Zielsystem schreibt.Vollständige Definition ansehen →-Job und warteten auf den Lauf um 2 Uhr morgens. Als der Alert feuerte, war die Ware verschickt und die Karte ausgereizt. Die Lösung war kein besseres Modell. Sie 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 kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen.

Dieser Wechsel, weg von der Frage an die Systeme „was ist der letzte Stand?" hin dazu, Systeme *ankündigen zu lassen, dass sich etwas geändert hat*, ist das Wesen von Event-driven Architecture. Als CDO verantworten Sie die Datenstrategie und die Governance darum bereits. Was die meisten Data Leader unterschätzen: **die *Architektur der Datenbewegung* ist ein strategischer Hebel, kein Installationsdetail**. Machen Sie es falsch, stirbt jede Echtzeit-Ambition Ihres CEO, Personalisierung, dynamisches Pricing, operative KI, 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, 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 Protokoll darüber, dass *sich die Welt bewegt hat*, und es kann nicht rückgängig gemacht werden.**

Diese Unterscheidung ist wichtiger, als sie klingt. In Ihrer traditionellen Welt ist die Source of Truth eine Tabelle, ein Snapshot des *aktuellen* Zustands. Die Adresse eines Kunden ist, 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 eines Replays aller AddressChanged-Events.

Das ist der Wechsel des Denkmodells, den die meisten Führungskräfte übersehen, deshalb mache ich es mit den praktischen Konsequenzen konkret:

• Zustand wird rekonstruierbar. Wenn ein Downstream-System seine Daten korrumpiert, spielen Sie das Event-Log erneut ab und bauen es neu auf. Batch-Pipelines können das nicht; die Quellzeilen sind längst überschrieben.
• Neue Consumer können spät dazukommen und bekommen trotzdem Historie. Ein Team baut sechs Monate nach Launch einen ML-Feature-Store 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 können fragen „was wussten wir um 15:14 Uhr?", entscheidend für Audit, Modell-Debugging und regulatorische Rekonstruktion.

Das Fraud-Problem des Händlers war im Kern, dass **ererDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.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 die Governance-Instinkte des CDO in die Architektur hineinreichen. Ein Event ist ein veröffentlichter Contract zwischen dem, der es produziert, und allen, die es konsumieren. Das Schema von `OrderPlaced`, seine Felder, Typen und Bedeutung, wird zu einer gemeinsamen API im ganzen Unternehmen. Ändern Sie es unbedacht, brechen Sie Systeme, von denen Sie noch nie gehört haben.

Deshalb betreiben ausgereifte Streaming-Organisationen eine Schema Registry mit erzwungenen Kompatibilitätsregeln. Sie dürfen ein Feld nicht umbenennen, weil es für Ihr Team bequem war. Events sind strategische Assets, die genauso governed werden wie die Data Products in Ihrem Monetarisierungsportfolio: versioniert, mit Ownership, dokumentiert und per Policy backward-compatible.

Warum die Entkopplung von Producern und Consumern der eigentliche Gewinn ist

Der technische Vorteil, den alle nennen, ist „Skalierung". Das stimmt, ist aber oberflächlich. Der tiefere Gewinn ist *organisatorische Entkopplung*, und das ist ein CDO-Thema, denn Ihr Bottleneck ist selten Compute. Es ist die Koordination zwischen Teams.

In einer request-getriebenen Welt ist Integration Point-to-Point. Das Order-System ruft das Inventory-System, das das Loyalty-System, das das Analytics-System. Jeder neue Consumer bedeutet eine neue Integration, eine neue Abhängigkeit, ein neues Meeting. Mit *N* Systemen marschieren Sie Richtung *N²* Verbindungen, und jede einzelne ist eine Stelle, an der Ihre Architektur sich festfressen kann. Das ist die „Integrations-Spaghetti", die still und leise 40 % Ihrer Engineering-Kapazität verbraucht.

Event-driven Architecture dreht das um. Der Producer publiziert OrderPlaced in einen Stream und weiß nicht und interessiert sich nicht dafür, wer es konsumiert. Das Inventory-Team subskribiert. Später subskribiert das Loyalty-Team. Noch später subskribiert ein Data-Science-Team, um ein Churn-Feature zu bauen, ohne jemals mit dem Order-Team zu sprechen. Die Aufgabe des Producers endete mit der Veröffentlichung des Fakts.

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

Der organisatorische Payoff ist dieser: Teams liefern ohne teamübergreifende Verhandlung. Ihre Datenplattform ist keine Warteschlange von Integrationsanfragen mehr, sondern ein Marktplatz, auf dem Teams in ihrem eigenen Takt publizieren und subskribieren. Für einen CDO, der Datennutzung in einem Unternehmen skalieren will, das dem zentralen Team entwächst, ist das das einzige Modell, das funktioniert. Zentralisierte Point-to-Point-Integration skaliert ab einer bestimmten Organisationsgröße nicht, sie verwandelt nur Ihre besten Engineers in Vollzeit-Integrationsmakler.

Die Trade-offs, die Sie verantworten, nicht delegieren

Entkopplung ist nicht kostenlos, 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 einige hundert Millisekunden, manchmal Sekunden, widersprechen sich Bestandszahl und Order-Zahl. Ihre Business-Partner müssen verstehen, dass „Echtzeit" bedeutet „irgendwann, schnell und asynchron", nicht „überall sofort konsistent". Das ist ein Business-Gespräch, kein technisches.
• Debugging wird verteilt. Wenn etwas schiefgeht, ist die Geschichte über ein Dutzend unabhängig laufender Consumer verstreut. Sie brauchen Distributed Tracing und starke Observability *ab Tag eins*, nicht nachträglich nach dem ersten Incident.
• Reihenfolge und Duplikate. Streaming-Plattformen garantieren typischerweise *At-least-once*-Delivery, 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 als 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 Bindung über 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. Das ermöglicht Replay, Backfill und das Log als Source of Truth. Consumer verfolgen ihre eigene Position (das „Offset") und können zurückspulen. Kafka ist der richtige Default, wenn das Event-Log ein dauerhaftes Asset sein soll, wenn Sie sehr hohen Throughput 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 Denkmodell ist „liefere diese Message an Subscriber und dann weiter". Die Retention ist kürzer und Replay ist begrenzter. Im Gegenzug ist es dramatisch einfacher zu betreiben, vollständig serverless, nahezu kein Ops-Overhead, skaliert elastisch, 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 bringen würde:

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 eigentlich reines Notification-Problem nicht gebraucht hätten. Passen Sie die Plattform an den *Bedarf des Use Cases an Historie und Throughput* an, nicht an Résumé-driven Development.

Eine Konfigurationsidee, die es wert ist, verinnerlicht zu werden

Sie schreiben das nicht, aber Sie sollten erkennen, was es bedeutet, wenn Ihre Architekten darüber diskutieren. In Kafka setzt die Partitionsanzahl eines Topics die Obergrenze für parallelen Consumption:

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

Das eingebettete Urteil: Partitionen lassen sich später schwer erhöhen, ohne Ordering-Garantien zu brechen. Zu wenig, und Sie bremsen den Throughput; zu viele, und Sie verschwenden Ressourcen und verkomplizieren das Rebalancing. Wenn Ihr Team eine Entscheidung zur Partitionsstrategie verlangt, bittet es Sie eigentlich, den Trade-off zwischen kü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 angebracht ist***.

1. Echtzeit-Operational-Analytics und KI. Ihr Fraud-Beispiel, dynamisches Pricing, Recommendation Engines, Bestandsumverteilung, 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 höchsten 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 Ihren Feature StoreFeature StoreEin zentrales Repository zur Verwaltung von ML-Features, das Konsistenz zwischen Training und Serving sicherstellt.Vollständige Definition ansehen → zu streamen bedeutet, dass dasselbe Event, das den Betrieb steuert, auch das Modell steuert, und beseitigt den berüchtigten Training-Serving-Skew, bei dem Ihre Batch-Pipeline und Ihre Live-Pipeline Features unterschiedlich berechnen.

3. Change Data Capture (CDC) als Einstiegsrampe. Sie müssen nicht das Meer austrinken. CDCCDCVerfahren, das nur die geänderten Daten eines Quellsystems erkennt und weiterleitet, um nachgelagerte Systeme aktuell zu halten, ohne alles neu zu laden.Vollständige Definition ansehen →-Tools (Debezium ist das verbreitete) lesen das Transaktionslog Ihrer bestehenden Datenbanken und *emittieren jede Zeilenänderung als Event*, ohne die Quellanwendung anzurühren. Das ist der pragmatische Einstieg: Sie bekommen einen Event-Stream aus einem Legacy-System, das kein Konzept von Events hat, 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, subskribieren Sie 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 können.

Die Anti-Patterns, die Sie teuer zu stehen kommen

Sagen Sie Nein zu Streaming, wenn:

• Die Daten ihrer Natur nach wirklich Batch sind. Monatlicher Financial Close, Quartalsreporting, wöchentliches Modell-Retraining, das in Streaming zu zwingen bringt Kosten und Komplexität bei null Latenzvorteil. Nicht alles muss Echtzeit sein; „Echtzeit überall" ist ein Architektur-Smell.
• Ihnen die operative Reife fehlt. Streaming-Plattformen verlangen Observability, On-Call-Disziplin und Idempotenz-Strenge. Kafka einzuführen, bevor Sie das haben, produziert ein fragiles System, das still ausfällt und das Vertrauen in Daten erodiert, das eine Asset, dessen Verlust Sie sich nicht leisten kö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 Sie sollten sie nutzen.

Die strategische Rahmung für Ihre Peers im Vorstand: **Event-driven Architecture ist eine Investition in *Optionalität***. Sie zahlen heute eine Komplexitätsprämie, um künftige Use Cases günstig ergänzbar zu machen. 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 Messages. Erweitern Sie Ihre bestehende Governance-Disziplin in eine SchemaSchemaEin Schema ist der formale Bauplan, der festlegt, wie Daten in einer Datenbank, einer Datei oder einer Nachricht strukturiert, benannt, typisiert und miteinander verknüpft sind.Vollständige Definition ansehen → Registry mit erzwungener Backward Compatibility. Eine brechende Schema-Änderung ist eine brechende API-Änderung, und der Blast Radius liegt bei Ihnen.

1. Kaufen Sie Entkopplung, nicht nur Geschwindigkeit. Der strategische Gewinn ist, dass Teams ohne teamübergreifende Verhandlung publizieren und subskribieren. Wenn Ihre Datenplattform eine Warteschlange von Integrationsanfragen ist, löst Event-driven Architecture den Bottleneck auf, während die Organisation skaliert.

1. 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 operativer Last wollen. Lehnen Sie Résumé-driven Kafka-Adoption für Notification-förmige Probleme ab.

1. Starten Sie mit CDC, nicht mit einem Rewrite. Emittieren Sie Events aus Ihren bestehenden Datenbanken über Change Data Capture, um Einstiegswert aus Legacy-Systemen zu ziehen, ohne ihren Code anzufassen, und modernisieren Sie dann inkrementell.

1. Schreiben Sie Idempotenz und Observability ab Tag eins als Policy vor. At-least-once-Delivery bedeutet, dass jeder Consumer Duplikate sicher behandeln muss, und verteiltes Debugging verlangt Tracing vor Ihrem ersten Incident, nicht danach.