Event-driven Architecture

This item was not updated in last three versions of the Radar. Should it have appeared in one of the more recent editions, there is a good chance it remains pertinent. However, if the item dates back further, its relevance may have diminished and our current evaluation could vary. Regrettably, our capacity to consistently revisit items from past Radar editions is limited.

May 2022

Adopt

Consider using an Event-Driven Architecture in the following cases (taken from: Event-driven architecture style):

Multiple subsystems must process the same events.
Real-time processing with minimum time lag.
Complex event processing, such as pattern matching or aggregation over time windows.
High volume and high velocity of data, such as IoT. Be aware of the complexities and potential pitfalls involved when adopting this architecture. When using Even-Driven Architectures consider using Event Sourcing.

Sep 2021

Adopt

Decoupled systems that run in response to events. An event-driven architecture uses events to trigger and communicate between decoupled services and is common in modern applications built with microservices. An event is a change in state, or an update, like an item being placed in a shopping cart on an e-commerce website. Events can either carry the state (the item purchased, its price, and a delivery address) or events can be identifiers (a notification that an order was shipped). Event-driven architectures have three key components: event producers, event routers, and event consumers. A producer publishes an event to the router, which filters and pushes the events to consumers. Producer services and consumer services are decoupled, which allows them to be scaled, updated, and deployed independently. This also becomes a viable way for handling intra-service communication (pub/sub style). It should be preferred over direct intra-service API communication where possible.