Event-driven Architecture (EDA)
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.
When to use this architecture
- 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.
Components
An event-driven system typically consists of event emitters (or agents), event consumers (or sinks), and event channels.
Event emitters
Emitters have the responsibility to detect, gather, and transfer events. An Event Emitter does not know the consumers of the event, it does not even know if a consumer exists, and in case it exists, it does not know how the event is used or further processed.
Event consumers
Event consumers have the responsibility of applying a reaction as soon as an event is presented. The reaction might or might not be completely provided by the sink itself. For instance, the event consumer might just have the responsibility to filter, transform and forward the event to another component or it might provide a self-contained reaction to such event.
Event channels
Event channels are conduits in which events are transmitted from event emitters to event consumers. The knowledge of the correct distribution of events is exclusively present within the event channel.
The physical implementation of event channels can be based on traditional components such as message-oriented middleware or point-to-point communication
Pro and Con
Benefits
- Producers and consumers are decoupled.
- No point-to-point integrations. It’s easy to add new consumers to the system.
- Consumers can respond to events immediately as they arrive.
- Highly scalable and distributed.
- Subsystems have independent views of the event stream.
Challenges
- Guaranteed delivery. In some systems, especially in IoT scenarios, it’s crucial to guarantee that events are delivered.
- Processing events in order or exactly once. Each consumer type typically runs in multiple instances, for resiliency and scalability. This can create a challenge if the events must be processed in order (within a consumer type), or if the processing logic is not idempotent.
Reference
- https://en.wikipedia.org/wiki/Event-driven_architecture
- https://aws.amazon.com/event-driven-architecture/
- https://docs.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven
- https://microservices.io/patterns/data/event-driven-architecture.html
- https://solace.com/what-is-event-driven-architecture/
- https://www.redhat.com/en/topics/integration/what-is-event-driven-architecture
- https://www.nginx.com/blog/event-driven-data-management-microservices/