Lerne, wie du Event-getriebene Systeme baust, die auch unter Last nicht auseinanderbrechen.

Verteilter Monolith vs. EDA: Warum synchrone Microservices scheitern – und wie Events das lösen
Sicheres Publizieren: Wie du Events so produzierst, dass kein Datenverlust entsteht
Verlässlicher Konsum: Blocking Retry, Dead Letter Topics, Poison Pills – und wann welche Strategie greift
Orchestrierung vs. Choreografie: Wann du eine Workflow-Engine brauchst – und wann sie dich ausbremst
Saga-Pattern: Wie du verteilte Prozesse koordinierst, ohne verteilte Transaktionen zu brauchen
Schema-Evolution: Breaking Changes sicher ausrollen, ohne den laufenden Betrieb zu unterbrechen

Über den Autor

Lutz Hühnken ist Softwarearchitekt mit langjähriger Erfahrung in verteilten Systemen und Event-driven Architecture. Er baut und begleitet EDA-Systeme in der Praxis – von der ersten Architekturentscheidung bis zum Betrieb im Produktivsystem. In diesem Whitepaper teilt er, was wirklich funktioniert – und wo die Fallstricke liegen.

Autor des Whitepapers: Event-driven Architecture in Action

🔍 Frequently Asked Questions (FAQ)

Für wen ist dieses Whitepaper relevant?

Für Senior Developer, Tech Leads und Softwarearchitekten:innen, die verteilte Systeme bauen oder weiterentwickeln – und die verstehen wollen, wann und wie EDA wirklich hilft.

Was unterscheidet EDA von klassischen Microservices mit HTTP?

Synchrone HTTP-Kommunikation macht Services zur Laufzeit voneinander abhängig. Fällt ein Service aus, zieht er andere mit. EDA entkoppelt diese Abhängigkeit: Services kommunizieren über Events, nicht über direkte Aufrufe – und können unabhängig voneinander ausfallen, skalieren und deployt werden.

Brauche ich Apache Kafka, um Event-driven Architecture umzusetzen?

Kafka ist der de-facto-Standard für EDA – aber kein Muss. Das Whitepaper geht von Kafka aus, weil es sich in der Praxis bewährt hat. Die architektonischen Prinzipien gelten aber unabhängig vom Broker.

Was ist das Saga-Pattern – und wann brauche ich es?

Das Saga-Pattern koordiniert verteilte Prozesse ohne verteilte Transaktionen. Statt alles atomar abzuwickeln, definiert jeder Schritt eine kompensierende Aktion für den Fehlerfall. Du brauchst es, wenn mehrere Services an einem Geschäftsprozess beteiligt sind und du trotzdem auf „alles oder nichts“ angewiesen bist.