Ereignisgesteuerte Architektur
Bei ereignisgesteuerter Architektur melden Komponenten Ereignisse, auf die andere Komponenten unabhängig reagieren können.
Eine Änderung löst weitere Arbeit aus
Ereignisgesteuerte Architektur organisiert Zusammenarbeit über Ereignisse: Meldungen über etwas, das bereits geschehen ist. Produzenten veröffentlichen sie; interessierte Verbraucher verarbeiten sie über einen Ereigniskanal. Im erfundenen Beispiel meldet eine Anwendung die Freigabe eines Angebots. Planung und Berichtswesen können darauf mit verschiedenen Aufgaben reagieren.
Der Produzent muss dabei nicht jeden Empfänger direkt aufrufen. Die Entkopplung verlangt jedoch klare Ereignisbedeutung, Zuständigkeiten und Fehlerbehandlung. Doppelte oder verspätete Nachrichten sowie Reihenfolge können relevant sein. Das veröffentlichte Ereignis beweist noch nicht, dass alle Folgearbeiten abgeschlossen sind. Für einen einfachen Ablauf kann ein direkter Aufruf weniger Betriebsaufwand verursachen.
Quellen
Verwandte Begriffe
- Eventual ConsistencyEventual Consistency erlaubt vorübergehend unterschiedliche Datenstände, die unter den vorgesehenen Bedingungen wieder übereinstimmen sollen.
- Message BrokerEin Message Broker nimmt Nachrichten entgegen und vermittelt sie nach festgelegten Regeln an Empfänger.
- Publish-SubscribePublish-Subscribe verteilt veröffentlichte Nachrichten an interessierte Abonnenten, ohne dass der Sender jeden direkt ansprechen muss.
- Transactional InboxEine Transactional Inbox nutzt dauerhafte Nachrichteneinträge, um die lokale Verarbeitung gegen doppelte Zustellungen abzusichern.
- NachrichtenbestätigungEine Nachrichtenbestätigung meldet dem Broker, dass eine Zustellung nach der vereinbarten Regel angenommen oder verarbeitet wurde.
- Retry-JitterRetry-Jitter verteilt Wiederholungsversuche durch zufällig variierte Wartezeiten, damit viele Clients nicht gleichzeitig erneut anfragen.
Beiträge zum Thema
Schnittstellen & Integration mit ASES
ERP, CRM und Shop sauber verbunden