Software Architect’s library

Content

1. Intro
2. Example
3. Components
4. Pattern Analysis
5. Use Cases
6. Conclusions

1. Intro

The event-driven architecture (EDA) pattern is a popular distributed asynchronous architecture pattern used to produce highly scalable applications. EDA is made up of highly decoupled, single-purpose components that asynchronously receive, and process events.

2. Example

We will characterize EDA with an example of an e-commerce site. The architecture enables the site to react to changes from a variety of sources during times of peak demand, without crashing the application or over-provisioning resources.

Example of an event-driven architecture for an e-commerce site. (1)—Event Producers; (2) — Initial Events; (3) — Event Router; (4)— Processing Events; (5) — Event Consumers

3. Components

Event-driven architectures have five key components: event producers, initial and processing events, event routers, and event consumers. A producer publishes an initial event to the router, which filters and pushes processing events to consumers. Producer and consumer services are decoupled, which allows them to be scaled, updated, and deployed independently.

3.1 Event Producers

In the example, Event Producers are represented by a retail website, mobile application, and point-of-sale terminal. In principle, anything that registers a fact and represents the fact as an event message could be the producer.

3.2 Events

The initial event is the original event generated by the Producer and received by Router, whereas the processing events are ones that are generated by the Event Router and received by the Event Consumer components.

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

An event usually consists of two parts: 1) the event headerincludes information such as event name, time stamp, and type of event; 2) the event body provides the details of the state change detected.

3.3 Channels

Both initial and processed events are delivered by event channels.

Initial event channels could be a TCP/IP connection, or a file (XML, JSON, e-mail, etc.). Several initial event channels can be opened at the same time. They are read asynchronously, allowing near real-time event processing. The events are stored in a queue, waiting to be processed later by the Event Router.

Processing event channels aretypically represented by message queues and message brokers. Message brokers are most widely used so that the events can be handled by multiple Event Consumers (each performing a different task based on the processing event received).

3.4 Event Router

Event Router is responsible for identifying an initial event and then selecting and executing the steps contained within the event. For each step in the initial event, the Event Router asynchronously sends out a processing event to an event channel, which is then received and processed by the Event Consumer.

Event Router can also trigger a number of assertions. For example, if the event that comes into the event processing engine is a product ID low in stock, this may trigger reactions such as “Order product ID” and “Notify personnel”.

It is important to note that the Event Router doesn’t perform the business logic necessary to process the initial event — it distributes appropriate instructions (=processing events) among the Event Consumers.

3.5 Event Consumers

In the example, Event Consumers are represented by Management DB, Finance System, and Customers Relations office.

These components contain the application business logic necessary to handle the processing event. Event Consumers are self-contained, independent, highly decoupled architecture components that perform a specific task in the application or system. While the granularity of the Event Consumer component can vary from fine-grained (e.g., calculate sales tax on order) to coarse-grained (e.g., process an insurance claim), it is important to keep in mind that in general, each Event Consumer should perform a single business task and not rely on other consumers to complete its specific task.

4. Pattern Analysis

4.1 Scalability: high

Each event consumer can be scaled separately, allowing for fine-grained scalability.

4.2 Development complexity: high

Complicated due to the asynchronous nature of the pattern as well as contract creation and the need for more advanced error handling conditions within the code for unresponsive event processors and failed brokers.

4.3 Performance: high

High performance through asynchronous capabilities: the ability to perform decoupled, parallel asynchronous operations outweighs the cost of queuing and dequeuing messages.

4.4 Testability: low

While individual unit testing is not overly difficult, it does require some sort of specialized testing client or testing tool to generate events. Testing is also complicated by the asynchronous nature of this pattern.

4.5 Modifiability: high

Since event-consumer components are single-purpose and completely decoupled from other event consumer components, changes are generally isolated to one or a few event consumers and can be made quickly without impacting other components.

5. Use cases

5.1 Cross-account, cross-region data replication

Coordinate systems between teams operating in and deploying across different regions and accounts. By using an event router to transfer data between systems, you can develop, scale, and deploy services independently from other teams.

5.2 Fanout and parallel processing

If you have a lot of systems that need to operate in response to an event, you can use an event-driven architecture to fanout the event without having to write custom code to push to each consumer. The router will push the event to the systems, each of which can process the event in parallel with a different purpose.

5.3 Resource state monitoring and alerting

Rather than continuously checking on your resources, you can use an event-driven architecture to monitor and receive alerts on any anomalies, changes, and updates. These resources can include storage buckets, database tables, serverless functions, compute nodes, and more.

5.4 Integration of heterogeneous systems

If you have systems running on different stacks, you can use an event-driven architecture to share information between them without coupling. The event router establishes indirection and interoperability among the systems, so they can exchange messages and data while remaining agnostic.

6. Conclusions

1. EDA uses events to trigger and communicate between decoupled services and is common in modern applications built with microservices.
2. EDA has the following key components: event producers, event channels, initial and processing events, event routers, and event consumers.
3. EDA is highly scalable, easily modifiable, and highly performant due to its asynchronous nature, but the pattern has high development complexity and is not trivial to test.
4. EDA use cases include cross-account and cross-region data replication; fanout and parallel processing; resource state monitoring and alerting; integration of heterogeneous systems.

Read more: Layered Architecture

References