Event-driven architecture
In event-driven architecture, components report events that other components can respond to independently.
A change triggers further work
Event-driven architecture organises collaboration through events: notifications of something that has already happened. Producers publish them; interested consumers process them through an event channel. In a fictional example, an application reports that a quote has been approved. Planning and reporting can respond with different tasks.
The producer need not call every recipient directly. That decoupling does, however, require clear event meanings, responsibilities and error handling. Duplicate or delayed messages and ordering may matter. A published event does not prove that all follow-up work is complete. For a simple workflow, a direct call may involve less operational overhead.
Sources
Related terms
- Eventual consistencyEventual consistency permits temporarily different data states that should converge under the intended operating conditions.
- Message brokerA message broker accepts messages and routes them to recipients according to defined rules.
- Publish-subscribePublish-subscribe distributes published messages to interested subscribers without requiring the sender to contact each one directly.
- Transactional inboxA transactional inbox uses durable message records to protect local processing against duplicate deliveries.
- Message acknowledgementA message acknowledgement tells the broker that a delivery has been received or processed according to the agreed rule.
- Retry jitterRetry jitter varies waiting times randomly to spread retries and reduce simultaneous requests from many clients.
Articles on this topic
APIs & Integration with ASES
ERP, CRM and shop cleanly connected