Event Driven Architecture

I work as a Software Developer at Netcompany where we create business solutions for clients in the public and private sector around the world. I’ve been exposed to an architecture that I never knew the value of called Event Driven Architecture. I’ve been developing multiple business solutions using this architecture for the past year now. In this article I will be sharing my experience with Event Driven and what value it brings compared to the standard ways of how microservices/applications communicate with each other using REST.

Microservices
You’ve probably heard of Microservices in the tech world. Microservices are an architectural approach to building applications. Following attributes that makes a application a microservice are:

• Small and single purposes
• Loosely coupled
• Independently deployable
• Organized around business capabilities
• Communication with each other using protocols.

Event Driven and REST Architecture follow these attributes when building microservices. Both architectures help developers to uphold these attributes but they differ from each other on how they do this.

What is Event Driven Architecture?

Event-driven architecture is a software architecture where it focuses on the capture, communication, processing and persistence of events. These events could be everything from changes in state for a system/software which either comes from internal or external inputs. External inputs would be; a user adding different products to their shopping cart and then hitting the order button. The system will then handle this as an OrderConfirmed event and send out a notification/message to all applications/microservices that are listening to this event. Same goes for Internal events, this will normally be created by the system. This could be creating events such as OrderApproved and OrderShipped. This will then allow a customer to get instant messages of how far their order has come.

Handling all of these activities/inputs toward the system as events gives us the opportunity to save them and always knowing the true state of the application, this is what we call Event Sourcing. When an object is changed/created it will be admitted as an event and then later on saved. Doing this will then give us the opportunity to replay all of the events in a correct sequence to reconstruct how the object was before it was lost or falsely manipulated. Using Event Sourcing with Event Driven architecture makes it easier to rebuild our databases if we were to lose them.

Today’s way of doing things
Most of today’s API’s are built using a REST Architecture where external microservices/applications have to do a request in order to get a response. This is today the standard way of designing microservices. Even though this way is a normal way of setting up API’s it also gives us some challenges in the future.

Let’s say for instance that you are working as a cashier at a fast food restaurant. Your job is to take orders from customers and also give them the food as soon it’s ready. Normally after your first customer has ordered their meal you would take on the next customer. But what if you were to only focus on finalizing the first order. You would be standing there waiting for the kitchen to finish up the meal so that you could hand it over to the customer. These challenges can occur when API’s are sometimes taking longer time to retrieve the information back to you.

Event Driven Architecture solves challenges like these. Asking multiple times and always getting the same answer will eventually cost you time. This is because your application won’t be able to do much until you get the information you need.

What Event Driven Architecture will do in this case is to allow you to listen to a specific event and retrieve that information. Your application doesn’t need to call anyone; it will get the information it needs when it’s ready. In this case you’ll know instantly when your order is finished without asking.

Business values

Event Driven Architecture provides also a great business opportunity. Applications are able to talk to each other seemingly without ever initiating the first request. Large companies that offer their customers multiple services on various applications can now easily work on making these applications work together. Let’s say for instance that a company offers cars to their customers. This car has multiple sensors that are tracking everything about the car for example tires, oil etc. The car knows already what type of tires and oil it uses and can easily send out an event to your car-shop application that the tires are soon wearing out. Your car-shop application receives this event and can start on setting up an order for the user so that they can get the tires before it’s too late. Everything happens instantly.

Functionalities like these are what most of the customers want today. Companies such as Apple are doing this already with their products. Where their products easily can connect and work fast together, creating this so-called ecosystem for their users. It’s convenience like this that makes a customer want to invest in all of your services.

Summary

In summary both of the architectures are solving the main issues we’ve had with applications that are built in a monolithic way. Applications with microservice structure can today easily share data with each other than before. Regardless of which of these you are using. It’s all based down to which architecture best suits for the project you are working on. It’s important to take a step back before always going for the “standard” way of building microservices. Look into the benefits of the architectures and also keep in mind the future business opportunity it might offer us later on.

Personally I would say I’ve had a great experience with EDA (Event Driven Architecture). It offers a lot of great possibilities for some companies with their journey of digitizing all of their services. I’ve had the first hand look of how applications can communicate with each other so seemingly. EDA is also easier for people with non-technical background to understand these events since they are reflecting the domain. Which makes the communication bridge between people with technical and non-technical backgrounds closer.