INFO Technology RadarINFO Technology Radar

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.
Adopt

Event-driven architecture is less a technology choice than a way of thinking about systems. Rather than components calling each other to make things happen, they publish facts about what has happened, and other components decide for themselves what to do with them.

We use this approach, and we use it deliberately. It is not free: asynchronous flows are harder to follow than a call stack, delivery is typically at-least-once so consumers have to be idempotent, eventual consistency has to be a decision rather than a surprise, and debugging spans several components, which means tracing has to be in place from the start rather than added once something goes wrong.

As with any architecture, the right answer is the one that fits the problem. Event-driven is one of the approaches we reach for, not a default we apply everywhere.

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.
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.