by Santiago Arango, Software Architect at Growth Acceleration Partners
Hello dear reader! I am happy you are here. So, I am not going to take your time telling you who I am; we will go over that by the end of the post. If you get there, it means I managed to get your attention, which is good!
Now, in this blog post, you will find a very accessible and effortless way to understand event-driven architecture, how it can be used, and what its purpose is, along with the advantages of adopting this kind of design in your products.
I will split the topic into smaller pieces, and then I will provide you with a sample using those components. Also,the reader must understand cloud providers like Azure, AWS, GCP and others that would help you easily understand some terminology is NOT what’s going to be explained in detail here.
Event Driven in the real world
Let’s keep it simple at first. In our daily lives, we live through events. Events are nothing more than actions you can execute at any time, but you might not get a result in real-time; you may have to wait for some time.
Let’s take buying a car as an example. You head to the dealership and choose the car you like that fits your requirements. Now, a couple of things could happen here. The dealership might ask you for an advance payment for the car, and then your request goes into a queue with other clients who also bought cars.
Here, things can change depending on many factors. If you buy a standard car with a lot of marketing and sales, you might end up in a bigger queue. But, at the same time, the factories usually produce these kinds of vehicles more often due to the high sales figures. On the other hand, if you buy a premium car, which has a smaller buyer list, you might have to wait longer for the production and delivery, since they are more complex and time-consuming.
Image produced with MidJourney AI
From this example, we can abstract the action of buying a car as an event. The seller puts your order into a queue, and the factory processes the orders likely in the order they arrived, but they would split the list according to the type of vehicle you asked for. So, as you can see, the factory is a consumer because they pick up the events and process them. However, even though they are consumers, the factory can also be a producer.
After the factory completes the production of the car, they create another event to notify the transportation area to pick up the cars and move them to the target destination. Eventually, the car arrives at the dealership, triggering another set of events. For example, one event could be preparing the car by cleaning, washing, and waxing it. When this event ends, the seller will reach out to you, and then you will get your brand-new car!
As you can see, when you trigger the first set of events, many other events happen one after the other, and you may not be aware of all of them. What you care about is getting your brand-new car when the time comes. However, it doesn’t mean all events must happen one after the other. For example, when the company ships the car to the location, the dealership may do a bunch of things at the same time, such as creating invoices, charging you with the rest of the payment, paying insurance, registering your car with the local authorities as the owner, among other tasks.
Base participants in an Event Driven Architecture
Now, let’s translate some basic concepts from the real-world example. As you might have noticed, we have events, consumers, producers, and queues. Let’s give a brief description of each one of these parts, so we can mix them into an architectural design.
Events
As the name suggests, an event is something triggered by a particular action. This action can be started by the end-user, other software components, or events that trigger other events. For example, when you tap your phone to open an application, you produce an “On Click” event. The software on your phone will pick up the signal produced by the tap and continue to open the application you selected.
It’s important to note sometimes you may have to wait for a response after triggering an event, which means it acts as an asynchronous event that will give the response some time in the future. For example, when you place an order for a car, the manufacturing request may be taken later. This is like what happens when you place an order on an e-commerce site like Amazon. You may have to wait for a few minutes or even days until they confirm the seller has the product and then try to charge your credit card.
Image produced with MidJourney AI
Producers
Now this one is quite simple; the producer is the entity, or maybe even other events that trigger events. As an example from the dealership, when you pay and reserve the car, you were the producer of an event of buying a car, so you produced that message by making the purchase.
In a software example, you are also a producer when you buy something on Amazon; for example, you produce an order that will be processed by the right services.
Consumers
Consumers are one or more entities that listen to produced events. Usually, software events are wrapped up in structures that can be easily understood between applications. For example, JSON or XML formats are quite popular, since most programming languages or PaaS platforms support them. The consumers’ jobs can vary according to the system’s requirements. They can transform messages into something different and send those messages to other consumers, or they can be at the end of the road and do something specific with those messages.
This is where queues come into play, as we mentioned earlier. A queue system is another software part whose main job is to take those messages, store them for some time, and then ensure they are received by the proper consumer or producer. The consumer can wait until the message is read and processed. Whatever implementation is used, queues implement robust and resilient strategies to ensure any message that arrives is processed, and in case of failure, it notifies the proper components.
AWS Services for Event-Driven Architectures
In this section, we are going to describe some AWS Services components that are super helpful for building event-driven architectures. Then, we will move to a chapter to deep dive into benefits, and finally, we will build the dealership example with components!
AWS Lambda
AWS Lambda is a serverless computing service that allows you to run code in response to events or triggers. It is a perfect fit for an EDA because it enables you to create small, independent functions that can be triggered by events, such as changes in a database or messages in a queue.
Amazon SNS
Amazon SNS (Simple Notification Service) is a fully managed messaging service that enables you to send messages or notifications to many subscribers or endpoints. It can be used to decouple your application components and let them know of events that occur in other parts of your system.
Amazon SQS
Amazon SQS (Simple Queue Service) is a fully managed message queuing service that enables you to decouple and scale microservices, distributed systems, and serverless applications. It can be used to transmit any volume of data, at any level of throughput, without losing messages or requiring other services to be available.
Amazon Kinesis
Amazon Kinesis is a fully managed streaming data platform that enables you to ingest, process, and analyze real-time streaming data at scale. It can be used to capture and process events from a variety of sources, including IoT devices, social media feeds, and web logs.
AWS EventBridge
AWS EventBridge is a fully managed event bus service that enables you to build event-driven architectures using events from AWS services, SaaS applications, and custom applications. It can be used to simplify the integration of your application components and automate workflows.
Step Functions
AWS Step Functions is a managed service provided by Amazon Web Services that enables users to build serverless workflows to coordinate distributed applications and microservices. With Step Functions, users can create complex workflows with conditional logic, error handling, and retry functionality through a visual interface. The service models applications as a state machine, where each state can execute AWS Lambda functions or other services. Additionally, Step Functions integrates with other AWS services and offers features such as parallel execution, nested workflows, and real-time monitoring, allowing users to build reliable, scalable, and fault-tolerant applications.
