Event-driven architectuur
Bij een event-driven architectuur melden componenten gebeurtenissen waarop andere componenten onafhankelijk kunnen reageren.
Een wijziging zet verder werk in gang
Een event-driven architectuur organiseert samenwerking via gebeurtenissen: meldingen over iets dat al is gebeurd. Producenten publiceren ze; geïnteresseerde consumenten verwerken ze via een gebeurteniskanaal. In een fictief voorbeeld meldt een toepassing dat een offerte is goedgekeurd. Planning en rapportage kunnen met verschillende taken reageren.
De producent hoeft niet iedere ontvanger rechtstreeks aan te roepen. Die ontkoppeling vereist wel duidelijke betekenissen van gebeurtenissen, verantwoordelijkheden en foutafhandeling. Dubbele of vertraagde berichten en volgorde kunnen relevant zijn. Een gepubliceerde gebeurtenis bewijst niet dat al het vervolgwerk klaar is. Voor een eenvoudige stroom kan een directe aanroep minder beheerwerk vragen.
Bronnen
Verwante begrippen
- Eventual consistencyEventual consistency staat tijdelijk verschillende gegevenstoestanden toe die onder de bedoelde voorwaarden weer moeten overeenkomen.
- Message brokerEen message broker neemt berichten aan en leidt ze volgens vastgelegde regels naar ontvangers.
- Publish-subscribePublish-subscribe verdeelt gepubliceerde berichten over geïnteresseerde abonnees zonder dat de afzender ieder rechtstreeks benadert.
- Transactionele inboxEen transactionele inbox gebruikt duurzame berichtregistraties om lokale verwerking tegen dubbele afleveringen te beschermen.
- BerichtbevestigingEen berichtbevestiging meldt aan de broker dat een aflevering volgens de afgesproken regel is ontvangen of verwerkt.
- Jitter bij herhaalpogingenRetry jitter varieert wachttijden willekeurig om herhaalpogingen te spreiden en gelijktijdige aanvragen van veel clients te verminderen.
Artikelen over dit onderwerp
Koppelingen & integratie met ASES
ERP, CRM en webshop netjes gekoppeld