--- term: 'Ereignisgesteuerte Architektur (EDA)' seoTitle: 'Ereignisgesteuerte Architektur: Ereignisse vs. Befehle' headline: 'Was ist eine ereignisgesteuerte Architektur (EDA)?' slug: ereignisgesteuerte-architektur category: backend-compute shortDefinition: 'Eine ereignisgesteuerte Architektur ist ein Entwurfsstil, bei dem Dienste unveränderliche Fakten als Ereignisse melden und Konsumenten unabhängig reagieren.' relatedTerms: - pub-sub-pattern - webhooks - database-triggers-beforesave-aftersave - microservices-vs-monolith contrastsWith: - api-orchestration aboutTerms: - 'Events vs. Commands' - 'Choreography' - 'Event Sourcing' faq: - question: 'Was ist eine ereignisgesteuerte Architektur, einfach erklärt?' answer: 'Komponenten verkünden, dass etwas passiert ist – ein Ereignis –, statt sich gegenseitig aufzurufen, und jede interessierte Komponente reagiert in ihrem eigenen Takt. Rundfunk statt Telefonat: Die Arbeit des Senders endet mit der Ansage, und Zuhörer kommen und gehen, ohne dass sich beim Sender etwas ändert.' - question: 'Was ist der Unterschied zwischen einem Ereignis und einem Befehl?' answer: 'Die Absicht. Ein Befehl ist eine Aufforderung an genau einen Empfänger, der sie ablehnen kann – ShipOrder. Ein Ereignis ist ein Fakt in der Vergangenheitsform, gesendet an alle, die es interessiert – OrderShipped. Die Falle ist der "passiv-aggressive Befehl": ein Ereignis, das insgeheim erwartet, dass ein ganz bestimmter Konsument handelt – also ein Befehl im Kostüm.' - question: 'Was ist der Unterschied zwischen ereignisgesteuert und Anfrage-Antwort?' answer: 'Die Kopplung in der Zeit. Anfrage-Antwort ist synchron – der Aufrufer wartet, braucht die Antwort und scheitert, wenn die Gegenseite nicht erreichbar ist. Ereignisse sind Fire-and-forget – widerstandsfähig und entkoppelt, aber letztendlich konsistent. Die Regel: Braucht der Aufrufer das Ergebnis zum Weiterarbeiten, dann Anfrage-Antwort; ist die Arbeit des Produzenten erledigt, bevor die Reaktionen beginnen, dann Ereignisse.' - question: 'Was ist der Unterschied zwischen EDA und Pub/Sub?' answer: 'Die Ebene. Pub/Sub ist ein Messaging-Muster – ein Zustellmechanismus, von Publishern über Topics zu Subscribern. EDA ist der Architekturstil, der üblicherweise darauf aufsetzt, zusammen mit Queues und Streams. Pub/Sub ist die Verrohrung; ereignisgesteuert ist die Entwurfsphilosophie, der diese Verrohrung dient.' - question: 'Was sind Event Notification, Event-Carried State Transfer und Event Sourcing?' answer: 'Fowlers drei verschiedene Muster, die sich unter einem Namen verstecken. Notification: dünne Ereignisse, Konsumenten fragen die Details nach. State Transfer: Die Ereignisse tragen die vollständigen Daten, Konsumenten halten lokale Kopien. Sourcing: eine Persistenzentscheidung – jede Änderung als Ereignis speichern und den Zustand per Replay rekonstruieren. Das dritte beschreibt, wie ein System Daten ablegt, nicht wie Systeme miteinander sprechen.' - question: 'Was ist der Unterschied zwischen Choreografie und Orchestrierung?' answer: 'Choreografie: Dienste reagieren auf die Ereignisse der anderen, ohne zentrales Gehirn – maximale Entkopplung, aber der Workflow existiert nirgends explizit. Orchestrierung: Ein Koordinator kommandiert jeden Schritt – sichtbar und debugfähig, um den Preis eines zentralen Kopplungspunkts. Die Regel: Orchestrieren Sie, wenn jemand für das Ergebnis geradestehen muss; choreografieren Sie, wenn Produzenten wirklich nicht interessiert, was danach passiert.' - question: 'Wie gehe ich mit doppelten und unsortierten Ereignissen um?' answer: 'Durch Entwurf, nicht durch Hoffnung: Broker liefern at-least-once, also müssen Konsumenten idempotent sein – nach Ereignis-ID deduplizieren oder Handler schreiben, deren Wiederholung folgenlos bleibt ("Status auf versendet setzen", niemals "umschalten"). Die Reihenfolge ist nur pro Partition oder Schlüssel garantiert; eine Architektur, die globale Ordnung verlangt, kämpft gegen ihr eigenes Transportmittel.' - question: 'Wann sollten Sie eine ereignisgesteuerte Architektur einsetzen?' answer: 'Wenn ein Fakt mehrere unabhängige Konsumenten hat, wenn die Last stoßweise auftritt und Puffern hilft, wenn Systeme sich integrieren müssen, ohne einander zu kennen, oder wenn eine Prüfspur der Änderungen einen Wert hat. Wann nicht: einfaches CRUD, Lesezugriffe, Operationen mit sofortiger starker Konsistenz und Teams ohne Appetit auf verteilte Systeme.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'What do you mean by "Event-Driven"? — Martin Fowler' url: 'https://martinfowler.com/articles/201701-event-driven.html' - name: 'Enterprise Integration Patterns — Messaging' url: 'https://www.enterpriseintegrationpatterns.com/patterns/messaging/' - name: 'Saga pattern — microservices.io' url: 'https://microservices.io/patterns/data/saga.html' - name: 'CloudEvents — CNCF specification' url: 'https://cloudevents.io/' - name: 'Event-driven architecture — Wikipedia' url: 'https://en.wikipedia.org/wiki/Event-driven_architecture' cta: title: 'Ereignisgesteuert ab dem ersten Tag' text: 'Auf Back4app ist jedes Speichern ein Ereignis: afterSave-Trigger reagieren serverseitig, Live Queries schieben Fakten zu den Clients, Webhooks tragen sie zu anderen Systemen und Jobs fangen die langsame Arbeit ab – EDA im Alltag, ohne Broker im Betrieb.' linkText: 'Kostenlos starten' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-09-27' translationKey: event-driven-architecture --- **Eine ereignisgesteuerte Architektur ist ein Entwurfsstil, bei dem Dienste unveränderliche Fakten als Ereignisse melden und Konsumenten unabhängig reagieren.** Die Präzision, die Anbieterseiten auslassen, steckt in zwei Wörtern: Ein Ereignis ist ein *unveränderlicher Fakt in der Vergangenheitsform* – `OrderPlaced`, nicht `PlaceOrder` – und der Produzent weiß nicht, wer reagiert, und es interessiert ihn auch nicht. Genau diese Gleichgültigkeit ist die Architektur: Konsumenten kommen hinzu, fallen weg und gehen kaputt, ohne dass der Produzent eine Zeile ändert – [Entkopplung](/glossary/de/entkoppelte-architektur/) im wörtlichsten Sinne. Und EDA ist ein Spektrum, keine Religion: Ein einzelner [Webhook](/glossary/de/webhooks/) ist ereignisgesteuert, eine ganze Streaming-Landschaft ebenfalls, und die meisten gesunden Systeme sind Mischformen. ## Das Wichtigste in Kürze | Frage | Antwort | | --- | --- | | Ein Ereignis ist | Ein unveränderlicher Fakt in der Vergangenheitsform – Konsumenten reagieren, ablehnen können sie nicht | | Ereignis ≠ Befehl | Fakten an alle Interessierten vs. Aufforderungen an genau einen Handler | | Die Entscheidungsregel | Arbeit des Produzenten vor den Reaktionen erledigt → Ereignisse; Aufrufer braucht die Antwort → Anfrage-Antwort | | Die drei Spielarten | Notification · Event-Carried State · Event Sourcing (eine *Speicher*-Entscheidung) | | Die laufende Rechnung | Idempotente Konsumenten, Korrelations-IDs, UX für Eventual Consistency | ## Ein Fakt, viele Reaktionen **JavaScript:** ```javascript // JavaScript — Cloud Code (cloud/main.js) // Everyday EDA: the write IS the event; consumers react independently Parse.Cloud.afterSave('Order', async (req) => { const order = req.object; const becamePlaced = order.get('status') === 'placed' && req.original?.get('status') !== 'placed'; if (!becamePlaced) return; // Consumers of one fact — none knows about the others: await Parse.Cloud.httpRequest({ // fulfillment system (webhook) method: 'POST', url: process.env.FULFILL_WEBHOOK, body: { event: 'order.placed', id: order.id }, }); await enqueueConfirmationEmail(order); // async job queue // Live Query pushes the change to every open dashboard automatically }); ``` **Flutter:** ```dart // Flutter / Dart — Back4app Flutter SDK // The client as event consumer: subscribe to facts, react on arrival final orders = QueryBuilder(ParseObject('Order')) ..whereEqualTo('status', 'placed'); final sub = await LiveQuery().client.subscribe(orders); sub.on(LiveQueryEvent.create, (order) => showNewOrder(order)); // Nobody called this screen — it REACTED to an event, like every // other consumer of "order placed": fulfillment, email, analytics. ``` **Swift:** ```swift // iOS / Swift — Back4app Swift SDK // The client as event consumer: subscribe to facts, react on arrival let orders = Order.query("status" == "placed") let sub = try await orders.subscribe() sub.handleEvent { _, event in if case .created(let order) = event { showNewOrder(order) } } // Nobody called this screen — it REACTED to an event, like every // other consumer of "order placed": fulfillment, email, analytics. ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK // The client as event consumer: subscribe to facts, react on arrival val orders = ParseQuery.getQuery("Order") orders.whereEqualTo("status", "placed") val sub = ParseLiveQueryClient.Factory.getClient().subscribe(orders) sub.handleEvent(SubscriptionHandling.Event.CREATE) { _, order -> showNewOrder(order) } // Nobody called this screen — it REACTED to an event, like every // other consumer of "order placed": fulfillment, email, analytics. ``` Ein Fakt – *eine Bestellung wurde aufgegeben* – und vier Konsumenten, von denen keiner die anderen kennt: eine Versandabwicklung, die per Webhook benachrichtigt wird, ein E-Mail-Job in der Queue, ein Analytics-Dienst, der mitzählt, und Dashboards, die sich über ein Live-Abonnement aktualisieren. Ein fünfter Konsument ändert stromaufwärts nichts. Das ist das ganze Argument, in einem einzigen Speichervorgang. ```mermaid flowchart LR accTitle: Produzenten, Broker und unabhängige Konsumenten in einer ereignisgesteuerten Architektur accDescr: Ein Produzent sendet ein unveränderliches Ereignis in der Vergangenheitsform an einen Broker. Der Broker stellt Kopien an unabhängige Konsumenten zu, darunter eine Versandabwicklung, einen E-Mail-Job, die Analytics und Client-Dashboards. Konsumenten lassen sich unabhängig hinzufügen oder fallen unabhängig aus, ohne dass sich der Produzent ändert, und jeder Konsument muss Duplikate idempotent verarbeiten. P["Produzent
Bestelldienst"] -->|"OrderPlaced
(unveränderlicher Fakt)"| B["Broker / Kanal
Topic, Stream oder Trigger"] B --> C1["Versandabwicklung
(Webhook)"] B --> C2["E-Mail-Job
(Queue)"] B --> C3["Analytics"] B --> C4["Dashboards
(Live Query)"] C5["Neuer Konsument,
am Dienstag ergänzt"] -.->|"abonniert – der Produzent
erfährt es nie"| B ``` ## Das Vokabular, entwirrt Das Begriffschaos der Suchergebnisse, aufgelöst in einer Tabelle – drei Nachrichtenarten, sortiert nach *Absicht*, nicht nach Transport: | | Befehl (Command) | Ereignis | Abfrage (Query) | | --- | --- | --- | --- | | Grammatik | Imperativ: `ShipOrder` | Vergangenheit: `OrderShipped` | Frageform | | Adressat | Ein Handler | Wer abonniert hat | Ein Antwortender | | Ablehnbar | Ja | **Nein – es ist bereits passiert** | n. v. | | Kopplung | Sender kennt den Handler | Produzent kennt niemanden | Aufrufer wartet | [Fowlers](https://martinfowler.com/articles/201701-event-driven.html) Warnung verdient ihr Zitat: Hüten Sie sich vor dem *passiv-aggressiven Befehl* – einem "Ereignis", das der Produzent sendet, während er insgeheim verlangt, dass ein bestimmter Konsument handelt. Bricht der Ablauf, sobald dieser Konsument nicht antwortet, war es von Anfang an ein Befehl, und die Bezeichnung "Ereignis" hat die Kopplung nur verdeckt. (Die Infrastrukturwörter – Broker, Router, Bus, Kanal, Topic – sind Beinahe-Synonyme für den mittleren Kasten; der [Artikel zu Pub/Sub](/glossary/de/pub-sub-muster/) behandelt diese Maschinerie, deren verallgemeinernde Architektur EDA ist.) ## Ereignisgesteuert vs. Anfrage-Antwort | | Anfrage-Antwort | Ereignisgesteuert | | --- | --- | --- | | Zeitliche Kopplung | Aufrufer wartet – Gegenseite muss laufen | Fire-and-forget – Konsumenten holen auf | | Die Antwort | Geht an den Aufrufer zurück | Es gibt keine Antwort, nur Reaktionen | | Fehlerverhalten | Sofortiger, sichtbarer Fehler | Widerstandsfähig – und letztendlich konsistent | | Debugging | Ein Aufrufstack | Korrelations-IDs über alle Sprünge | | Passend für | Lesezugriffe, Anmeldungen, Zahlungen – alles, was der Aufrufer *braucht* | Fakten mit unabhängigen Konsumenten | Die Regel in einem Satz: **Braucht der Aufrufer das Ergebnis zum Weiterarbeiten, dann Anfrage-Antwort; ist die Arbeit des Produzenten abgeschlossen, bevor irgendeine Reaktion beginnt, dann Ereignisse.** Die Bestellung aufzugeben verlangt eine synchrone Antwort ("hat es geklappt?"); alles danach – E-Mail, Versand, Analytics – sind Reaktionen auf einen Fakt. Genau deshalb sind reale Systeme Mischformen aus Absicht, nicht aus Kompromiss. ## Fowlers drei Spielarten – und wo Event Sourcing wirklich hingehört | Muster | Das Ereignis trägt | Konsumenten | Trade-off | | --- | --- | --- | --- | | Event Notification | Eine ID und kaum mehr | Fragen die Details nach | Einfach; der Rückrufverkehr koppelt wieder | | Event-Carried State Transfer | Den vollständigen relevanten Zustand | Halten lokale Kopien | Keine Rückrufe; Duplizierung und Veralten | | Event Sourcing | *Ist* das führende System | Rekonstruieren den Zustand per Replay | Perfekte Prüfspur; eine schwergewichtige Speicherentscheidung | Die Unterscheidung, die Meetings spart: **Event Sourcing ist, wie ein System Daten ablegt; EDA ist, wie Systeme miteinander sprechen.** Beides lässt sich kombinieren, keines setzt das andere voraus. Noch eine Linie, die Anbieter verwischen: Die *Zustellung* per Pub/Sub vergisst – wer spät abonniert, verpasst alles, was vorher gesendet wurde –, während *Streaming* (das geordnete Log nach Kafka-Art) sich erinnert und Konsumenten ab jedem beliebigen Punkt erneut lesen lässt; entscheiden Sie danach, ob die Historie Teil des Produkts ist. ## Choreografie vs. Orchestrierung | | Choreografie (EDA-typisch) | [Orchestrierung](/glossary/de/api-orchestrierung/) | | --- | --- | --- | | Koordination | Dienste reagieren auf die Ereignisse der anderen | Ein Koordinator kommandiert jeden Schritt | | Der Workflow lebt | Nirgends explizit – er entsteht | An einer sichtbaren, debugfähigen Stelle | | Kopplung | Minimal | Der Orchestrator kennt alle | | Fehlerbehandlung | Kompensierende Ereignisse, verteilt | Zentrale Retry- und Fehlerlogik | Die spiegelbildliche Regel, die sie mit dem [Artikel zur Orchestrierung](/glossary/de/api-orchestrierung/) teilt: **Orchestrieren Sie, wenn jemand für das Ergebnis eines Workflows geradestehen muss; choreografieren Sie, wenn Produzenten wirklich nicht interessiert, was danach passiert.** Lange fachliche Transaktionen über mehrere Dienste nehmen in beiden Fällen die Form einer [Saga](https://microservices.io/patterns/data/saga.html) an – lokale Transaktionen, verkettet durch Ereignisse oder durch einen Orchestrator, rückgängig gemacht durch Kompensationen statt durch Rollback. ## EDA im Alltag – ganz ohne Broker Der Abschnitt, den Architekturportale nie schreiben: Die meisten App-Entwickler betreiben längst ereignisgesteuerte Muster, ohne dass ein Message Broker in Sicht wäre. Ein [`beforeSave`/`afterSave`-Trigger](/glossary/de/datenbank-trigger/) ist ein Konsument von Datenänderungsereignissen. Ein [Webhook](/glossary/de/webhooks/) ist ein Ereignis, das über schlichtes HTTP Firmengrenzen überquert. Eine [Live Query](/glossary/de/live-queries-echtzeit/) ist Pub/Sub mit Clients als Subscribern. Ein [Hintergrund-Job](/glossary/de/hintergrund-jobs/), den ein Trigger in die Queue stellt, ist ein Ereignis, das asynchrone Arbeit auslöst. Die Code-Tabs oben zeigen genau diesen Stack – das Schreiben ist das Ereignis, der Trigger ist der Router, und die Konsumenten sind ein Webhook, eine Queue und ein Abonnement. Dedizierte Broker (Kafka, RabbitMQ, NATS – mit [CloudEvents](https://cloudevents.io/) als Standardumschlag) rechtfertigen ihr Betriebsgewicht, sobald Ereignisvolumen, Replay und teamübergreifende Verträge es verlangen; die *Architektur* beginnt viel früher, und die Frage "brauche ich einen Broker?" beantwortet sich meist von selbst: noch nicht. ## Typische Anwendungsfälle - **Bestell- und Zahlungsabläufe** – ein Fakt, viele Abteilungen: die kanonische E-Commerce-Pipeline. - **Systemübergreifende Integration** – Dienste verschiedener Teams reagieren ohne direkte Aufrufe und ohne gemeinsame Deployments. - **Echtzeit-Features** – Dashboards, Feeds und [Präsenz](/glossary/de/praesenz-online-status/) als Ereigniskonsum auf Client-Seite. - **Stoßweise Lasten** – Queues puffern die Spitzen, damit Konsumenten sie im eigenen Tempo abarbeiten. - **Prüfspur und Replay** – Streaming-Logs, bei denen "was ist wann passiert" selbst das Produkt ist. ## Sollten Sie ereignisgesteuert arbeiten? Eine Entscheidungsmatrix | Situation | Greifen Sie zu | | --- | --- | | Ein Fakt, mehrere unabhängige Konsumenten | Ereignisse – ihr Heimspiel | | Aufrufer braucht die Antwort, um weiterzumachen | Anfrage-Antwort, ohne schlechtes Gewissen | | Workflow mit Verantwortlichem und SLA | [Orchestrierung](/glossary/de/api-orchestrierung/) – kommandieren Sie die Schritte | | Reaktionen innerhalb einer App (E-Mail bei der Registrierung) | Trigger + Jobs – EDA im Alltag | | Firmenübergreifende Benachrichtigungen | [Webhooks](/glossary/de/webhooks/) | | Streams mit hohem Volumen, Replay und mehreren Teams | Ein echter Broker – jetzt hat er sich seinen Platz verdient | ## Grenzen und Trade-offs - **Dem Debugging fehlt der Aufrufstack.** Eine Anfrage, die sich in fünf asynchrone Sprünge auffächert, ist nur über Korrelations-IDs nachvollziehbar, die ab dem ersten Ereignis mitgeführt werden – nachrüsten ist eine Qual; verdrahten Sie sie ab dem ersten Tag. - **Eventual Consistency reicht bis in die Oberfläche.** Der Nutzer ändert sein Profil, und der nächste Bildschirm zeigt den alten Namen; entweder Sie gestalten die UX dafür, oder Sie halten diesen Pfad synchron. - **Duplikate gehören zum Vertrag.** At-least-once-Zustellung macht idempotente Konsumenten zur Pflicht – [derselbe Vertrag](/glossary/de/hintergrund-jobs/), den Queues auferlegen, weil es dieselbe Maschinerie ist. - **Schemas ändern sich unter den Füßen der Konsumenten.** Ereignisse sind Verträge mit unbekannten Subscribern: nur additive Änderungen, versionierte Topics für Brüche und überall tolerante Leser. - **Entstehende Workflows verstecken sich.** Reine Choreografie heißt, dass niemand auf den Geschäftsprozess zeigen kann; sobald Prüfer oder Kollegen in der Rufbereitschaft das brauchen, ergänzen Sie den Orchestrator. ## Ereignisgesteuerte Muster mit Back4app Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Der Abschnitt zur Alltags-EDA ist die Feature-Liste der Plattform, gelesen als Architektur: Jedes Speichern ist ein Ereignis, [`afterSave`-Trigger](/glossary/de/datenbank-trigger/) sind serverseitige Konsumenten mit dem vollen JavaScript-Ökosystem, [Live Queries](/glossary/de/live-queries-echtzeit/) verteilen Fakten über verwaltete WebSockets an die Clients, [Webhooks](/glossary/de/webhooks/) tragen sie zu externen Systemen, und [Hintergrund-Jobs](/glossary/de/hintergrund-jobs/) fangen die langsamen Reaktionen ab – die Code-Tabs zeigen die gesamte Schleife ab einem einzigen Bestellvorgang. Die Disziplinen, auf denen dieser Artikel besteht, bleiben Ihre (idempotente After-Hooks, Denken in der Vergangenheitsform, synchron dort, wo der Aufrufer Antworten braucht), während die brokerförmige Infrastruktur – Fan-out, Zustellung, Verbindungsflotten – als Plattformverhalten geliefert wird; und der spätere Umstieg auf einen dedizierten Streaming-Broker ist eine Ergänzung dieser Architektur, keine Neufassung.