What are event driven architectures?

A couple of years ago, I was part of group of individuals working on defining different Event Driven architectures during a weekend summit. A summary of the summit was already published by Martin Fowler as first as a blog and later as a talk, the blog takes a slightly different view than the explanation I needed and thus this post was created. This is a recreation of the contents in the talk. If you have watched it, you can skip reading this summary.

What is event driven?

This technique is a popular technique to avoid coupling in systems. These systems tend to eventually become good sources of data that the business would like to build data platforms, insights and models on.

This page exists to

1. Help understand the different patterns at a high level
2. Understand the implications on building data systems

Events vs Commands

An event is when a system wants to announce what has happened but not what is to be done. For example, a new insurance quote being generated is an event. It announces to the world that a quote has been generated but not what should happen as a result.

A command is when a system wants something to be done and is asking a system to do it. For example, an upstream system might ask the communications system to send an email with specific details and this is a command to the communications system.

Both of these are usually implemented as events on a queue. The primary differences are how they are named and what the intent is.

Different types of event driven patterns

Let’s start with an example to help visualise the problem in which the customer changes an address for their house insurance in an insurance provider’s system which leads to a new quote being generated. This quote needs to be sent back to the user via an email.

If the services are built as visualised with calls across services being made, the services will be tightly coupled in their flow (since customer management needs to know of the existence of the quoting system which in-turn needs to know about the existence and need for communication). Here is how that problem can be solved with event driven architectures.

Event notification pattern

In this pattern, a source system will send a “notification” to all other systems that something has happened. The consumer needs to setup an event listener and figure out how to react to it. An example of this can be seen by the customer management system generating

Since the events do not have any information about what has changed, the downstream systems still need to call the upstream system to understand the details of what has changed to take action on the changes.

Here are a couple of versions of the customer changed event. The first version is one where the customer address changed event could include only the ID of the customer who’s address has changed. For every other part of the information (including what’s changed), the downstream systems need to contact the customer mamangement service.

Of course, these additional questions could be included in the event notification because they are related to the core event itself. There will always be some fields that a downstream system might need that are not directly part of the event but are required by the downstream system.

Advantages of using Event Notification

Systems built are decoupled. When there’s other actions that need to be made based on an address being changed, it’s easy to add another system to take action on this event without changes being required on the customer management side.

Downsides of using Event Notification

Systems built will be devoid of any behavior and there is no easy way to trace what happens downstream. There is no easy way to trace all the changes that happen in the code (by looking at the source code) to understand the list of changes that happen when the user changes their address.

Distributed tracing systems like zipkin aim to address these challenges by allowing visualisation of flows on environments with a full setup. Code can be traced by using mono-repos with the event names being the same across services. These are techniques to deal with the inability to trace code/flows across systems and while neither of them are as effective as tracing usages of your code, they help drive a balance between decoupling and ease of use.

Even when all the related information to the event have been added into the event payload, there will still be a need for downstream systems to require information. This means additional API calls will have to be made to the upstream system. As more downstream systems subscribe to a particular event, the upstream system will be under higher load to provide access to information and the downstream system’s availability is depedent on the upstream system.

Event carried state transfer pattern

Event carried state transfer (or ECST, for short) is sends all information related to the domain object in the event to avoid Event Notification’s need for call backs for additional information.

Downstream systems need to store the parts of the information they need for their usecase. If a difference between the old and new data is required, the data-structures chosen should make calculating differences easier.

Advantages of using ECST

Systems using this pattern have a lower dependence on their upstream services and thus have higher availability.

Downsides of using ECST

The higher availability comes at the cost of making the system eventually consistent. The data will also have higher replication.

Event sourcing

An event sourced system is one where the events are stored on an event store/event log and where the current application state can be completely recreated based on the event store.

The event store is an append only log of events that have occurred and, in the example, the customer DB is an example of a snapshot. A snapshot is required for enhancing the performance of your store (since it stores the current state of your system for quick access).

Both source control systems (like git, svn etc.) and financial accounting ledgers are good examples of event sourcing.

Advantages of using Event Sourcing

This system makes audit, debuggability and replayability simple. Such systems are great to recreate issues and understand what order things happened in. The ability to timetravel with data on a production system is quite useful. Concepts like branching is possible with data and what-ifs are easy to simulate to figure out the difference. Differences can then be applied through the creation of compensating actions.

Downsides of using Event Sourcing

This system will make event versioning mandatory. Interacting with external systems becomes more complicated since these calls are side-effects and event sourced systems should not cause this side-effect again when events are being replayed.

Command Query Responsibility Segregation pattern

Command Query Responsibility Segregation (or CQRS, for short) is a model in which reads and writes are separated. This allows scaling and optimisation reads and writes separately as per requirements.

Advantages of using CQRS

This pattern is rarely necessary but extremely useful to allow write heavy vs read heavy transactions to be scaled separately. The read side(s) can be optimised for the usecases they are being used for.

Downsides of using CQRS

Adds significant complexity building and maintaining a system.

Reading material

1. What is event driven?
2. The many meanings of Event-Driven Architecture?
3. Axon framwork - Framework for event driven, event sourced, CQRS powered applications in Java
4. Event Sourcing: A Practical Guide to Actually Getting It Done

Comments