An introduction for event driven architecture on AWS. Part 2

by Santiago Arango, Software Architect at Growth Acceleration Partners

In “An introduction to event driven architecture on AWS. Part 1” I wrote about event-driven architecture, how it can be used, base participants and AWS services. Welcome back for Part 2.

Benefits of AWS Event-Driven Architecture

Okay, now that we understand the basic parties involved in event-driven architecture (EDA), let’s dive into the technical details and explore the advantages of using EDA in your product.

EDA offers immense value to software by supplying scalability, lower latency, resiliency, and cost minimization. Why? Because EDA enables you to build highly available products that can withstand technical failures in some components without fully affecting the entire system (unless there is a massive failure that affects services by region).

For example, let’s say you’re ordering a car online. You choose your car with all the details you prefer and then place your order. Later that day, you receive an email confirming your order was placed correctly and accepted by the dealership. Now, you need to make your payment. However, at that exact moment, the service that generates invoices is down.

But that doesn’t stop you from making your payment. In an EDA system, the payments and invoice services are not connected. Instead, the payments service adds a new message to a queue, and the message sits there until the invoice service takes it and processes it. Sometime later, when the invoice service is back online, you will get your invoice, and the process of getting your new car will continue.

Now, if the same scenario happened in a traditional architecture where the user must wait until the system processes everything and the invoice fails, you would have to call the dealer, they would have to verify your payment, then ask someone to process the invoice properly. This is because the components are tightly connected as a single process.

Dealership Sample with Event-Driven Architecture using AWS Services

Diagram A: EDA with AWS for a Dealership

In the image above, you see an example of how an EDA system can interact. This example uses AWS Services, like Lambda, SQS (Simple Queue system), RDS (Relational Databases), SNS (Simple Notification System), and step functions.

Let’s split it into smaller pieces:

1. The user interacts with the dealership website, via the browser, and makes the order.
2. A Lambda function, which is triggered via HTTP, picks up the request and places the message into an SQS.
3. There is an order processor, which is another Lambda, which is triggered when a new element is added to the queue. This Lambda adds the order to a database using RDS, notifies the dealership via email that a new order has been placed, and triggers a new step function!

Dealership Sample with Event-Driven Architecture using AWS Services — After Order

In the earlier section, we triggered a step function. The great thing about step functions is they allow you to create states for your application, which is perfect for our case. If we follow the process of delivering a car after you place an order and the dealership confirms it, it can be summarized as follows:

Diagram B: Basic flow

Now all these steps can be easily adapted to our application using EDA. As you see, this is going to be a perfect scenario for step functions because we will have several states for the vehicle from now on.

1. On Order Arrived
2. On Production Started
3. On QA after production
4. On QA — Failure
5. On QA — Success
6. On Delivery
7. On Dealership
8. On End

Each one of the states would be set by a user. This will be done via an event according to the result of the previous one. Let’s draw it as part of the Step Function!

Step functions to change states

Diagram C: Design to update status

Let’s take a look at what we have on Diagram C. Here, we can easily summarize all the step changes into a single design by changing something according to the current step. One thing that will not change during the entire process is that someone will be using an application to see the status and update it to the next step. For example, a manager might be the one to see the orders in the queue for the different assembly lines and choose which one should go into production next. When the car is in production, the assembly line boss would be responsible for updating the status. The same applies to the QA lead, delivery area and so on.

What can change here is the Lambda function titled in the diagram as “Function Update Status.” You can easily see it this way: a Step Function is used to have several states on which actions are triggered, and for each action, you can have something associated with it. You can trigger a Lambda function, add messages to SQS, send notifications via SNS, and more.

This can be taken to mean each step on the function can trigger a unique Lambda function and do whatever it needs to do according to the state. For example, when the car fails the QA process for some reason, maybe they not only want to update the status but also send custom emails to the heads of operations so they are aware of the low quality. Another example is when the car leaves to be delivered, the dealerships receive a delivery note with the cars that are coming their way.

Closing Notes

One small note I want to give to you, my dear reader, is that if you design an application following this pattern, it is simple and easy to scale, especially if you are using services like AWS. If this app is your product and you start selling it, it would be ready to handle one or thousands of dealerships easily. This design also gives you heavy resiliency, using queues, step functions, notification services, and others in the cloud, which give you flexibility if one part of the process fails. The services can come back online later and do their job, unlike standard architecture, where it’s all or nothing.

We keep it simple here, but you could easily integrate services like EventBridge and add one or more queues for the delivery lines to increase scalability and make your design more solid and stronger. But even with a simple connection of services, you could supply a great solution!

And finally, as promised, I am Santiago Arango. I have been working in the software industry for 12 years, mostly as a software developer, technical lead of engineering, and now, in my most recent job, as a software architect.

On our next post about Event-Driven Architecture

In my next blog post, I’ll be back, deep diving into more technical implementations: We will go over some code and instructions to deploy it in the cloud, so you can test it yourself. Stay tuned!