Software Architecture Patterns — Event Driven Architecture

Welcome back to the Software Architecture Patterns blog series. This is the 4th chapter of the series and we’ll be talking about the Event Driven Architecture Pattern. Now we will move on to talk about distributed architectural patterns. Hopefully, by the end of this post, you’ll have an understanding of this particular architecture pattern and how it can benefit you. So let’s get to it!

This blog goes as a series and we will be covering the following topics as the main chapters of the series.

1. What is a Software Architecture Pattern
2. Layered Architecture Pattern
3. Microkernel Architecture Pattern
4. Event Driven Architecture Pattern (this post)

Distributed architecture allows us to run applications in multiple process spaces. It allows us to produce highly scalable and adaptable applications that can be used for either small or large, complex applications. One type of distributed architecture is the event-driven pattern of which there are two main topologies, the mediator and the broker. While both topologies go under the event-driven pattern, it is important to understand their differences to find which one is best suited for the application.

Broker Topology

This architecture structure consists of an event channel (i.e. the message queue), an initiating event and a service or event processors. The components work as follows:

1. The initial event kicks off a process into the event channel.
2. The event channel sends this message to the event processor.
3. Once the event processor receives this message and acts on it, it may send messages to other event processors.
4. The other event processors will process these new messages and may relay more messages to other ‘listening’ event processors and so on.

To demonstrate the above process, let's take the workflow of an insurance company where a customer wants to change his or her address.

1. When the customer moved, an initiation event is created and will be handled by the customer processor.
2. The customer processor will go through the customer records and update their address.
3. Once updated, the customer process will post a message to a message queue for the other event processors. Those that are ‘interested’ in address changes will ‘listen’ and respond.
4. In this case, both the quote and claims processes are listening and will pick up this change address message from the message queue.
5. The quote processor will update the quotes and recalculate it on behalf of the customer. After that it will send a message to the notification message queue.
6. Simultaneously, the claims process will handle the change of address message by updating claims. After that it will post a message to the message queue for anyone interested in updated claims.
7. Both the notification and adjustment processors pick up this message and generate an email to the customer, indicating that all work has been done.

As can be seen, this topology is useful when you have a fairly simple event processing flow. However, there are three common challenges when implementing this type of pattern.

• Error-handling

If the claims processor dies while performing the claims adjustment, the message is destroyed. Thus, the notification process will not occur. In this case, an error handling method like error queues or a verification message (to manage errors) must be implemented.

• Sending the Unified Notification Message to the Customer

As there is no central system for processing messages, all coordination happens at the end. This is troublesome because when we want to send a unified notification to the customer, it will only happen at the end. Hence, the system should orchestrate all events and make sure the intended process executed correctly in distributed nodes.

• Evolution

Evolution is easier with this architecture. We can easily add an auditing process when modifying claims. To add this behaviour, we tag an auditing process onto the message queue. The challenge here is keeping track of additional processes that will be attached over time.

Despite these issues, the main advantage of this topology is that things can be processed in parallel.

Mediator topology

The other flavor of event-driven architecture is the mediator topology. Here, an initiating event kicks things off and follows event queues similar to broker topology. However, it has a different architectural component called an event mediator. All requests go through this mediator where it will post messages to other message queues. These are then wired to event processors to be processed. The event mediator can be a simple one like Spring coordination, Mule, Enterprise Service Bus, or Apache Camel. Or it can be a more complicated one like business execution languages or business process management tools.

If one event processor needs to send a message to another event processor, it is never done directly. The message always goes through the mediator because the workflow is defined at that mediator level. 

To demonstrate the mediator topology, let’s return to the same example we looked at before. When a moving event is generated, it goes into the process engine within the mediator. The mediator has a business workflow where it updates the address, recalculates quotes, updates and adjusts claims, and notifies the insured. As this is also an event-driven architecture, it allows these workflows to be done in parallel similar to broker topology.

Let's see how mediator topology addresses the problems we talked about in broker topology.

•  Error-handling

By having a mediator, we can coordinate the business workflow accordingly to how it’s supposed to take place. For example, we can make sure that any recalculations are done prior to any adjustments. Thus if there are any errors, these can be handled before processing.

• Unified notification message

Here the workflow ends before notifying the customer. The mediator monitors each processor and thus only once everything is completed will the unified notification messaged be sent to the customer.

• Evolution

If we want to add the auditing capability to this structure, it will not be easy. We’d have to add the audit process first and then update the mediator. The audit process is added as a part of the workflow thus, there would be multiple places where this would need to be updated in the architecture.

The drawback of this topology is that when a mediator is introduced, you have to introduce a group of people to manage that mediator.

Now we’ll have a look at the pros and cons of event-driven architecture. 

Pros

• We can easily add extra functionality to a system built based on this architecture. The components are isolated and decoupled from other processes and thus any changes won’t impact the existing functionality.
• Due to the decoupled nature of the event processors, it is easy to deploy.
• Performance and scalability are considered great because multiple processes can be run in parallel.

Cons

• It is harder to test due to the asynchronous aspects of the system. We should have a very good event orchestrator to coordinate this.
• It is not simple as development can be somewhat complicated for the same reason above. Also, more advanced error handling conditions for unresponsive event processors and failed brokers must be handled as well.
• It is expensive to implement because of the coordination and the extra amount of work that must be done to build a system.

Stay tuned to this blog series as we will be discussing how to apply most common software architecture patterns. The next post of this series will discuss the Pipeline Architecture pattern.

If you have any queries/concerns, then you can drop me an email or send me a message on LinkedIn or Twitter. I’m just a message away :)