Event Driven Architecture (EDA): Demystifying EDA

Part of the Event Driven Blog Series

What We’ll Cover:

• What is event driven architecture?
• Sync vs async communication
• What is an event?
• Benefits of EDA and Use Cases
• AWS EDA offerings

What is Event Driven Architecture?

Event Driven Architecture (EDA) is a software engineering design pattern that decouples communication between applications and as we will see is particularly useful with microservice architectures.

Typically an application service publishes events to an event broker (more on this later), and consumers can asynchronously subscribe and independently react.

Event Driven Architecture is commonly used when developing enterprise IT systems as it allows information to flow in real-time and allows loosely coupled service teams to work without dependencies focusing on delivering their pocket of business value.

What is EDA? “An Architectural Style of building loosely-coupled software systems that work together by emitting and responding to events” — Brian Zambrano, AWS

What is Asynchronous Communication?

Asynchronous communication is when two or more entities in a system (the sender and receiver) operate independently of each other. In contrast, synchronous communication is where the entities are connected and wait for each other’s responses.

What is an “Event”?

An event is a change of state, often referred to in software engineering as “Facts”. Events contain context of something that has happened, in the past. They are immutable (cannot be changed).

A few examples of events are could be “Order Created”, “Order Dispatched” or they could originate from IoT devices — sensor readings etc.

Events are often confused with Commands. Let’s discuss the difference.

What is a “Command”?

While an event is a fact about something that has happened, a command is an instruction to perform an action. Commands can trigger a change in state and cause events to be raised.

Where events are things that occur in the past, commands are typically future-orientated.

A few examples could be “Send Email” or “Deduct Stock” or again in an IoT example could be “Capture Reading”.

Why should we use Event Driven Architecture?

A common communication pattern that a vast number of software systems use today is API-driven; one system calls another and waits for a response from the intended consumer. The consumer can either respond straight away with an update or they could take seconds, minutes, hours or even days to process when using technology such as web sockets or long-polling techniques.

While waiting for a response, the source application is busy constantly checking for updates and sometimes this can block other communication from happening entirely.

Using events accelerates productivity by enabling the business to react or adapt quickly and effectively to something that has happened. You can respond to a customer update, map closely to a business process or if required reallocate your resources.

Event Driven Architecture brings technology closer to the heart of your business. You can model events that happen in your system with business events (through Domain-Driven Design, more on this later).

Advantages of EDA

1. Event driven systems are non-blocking by design — publishers can continue with other tasks in parallel, without waiting for a response that may not even be required.

2. Services are decoupled — they can function independently. If one service is offline the other one can continue with other responsibilities.

3. Event Driven Architectures are flexible — systems can react to events at their own pace, store events for later consumption and allow contingency for delays or temporary unavailability without causing a disruption to your business.

4. Scalability by design — Services can handle multiple tasks concurrently, process at their own pace and manage peak traffic without causing throttles and downtime.

Use Cases for EDA

As we have already talked about, event-driven architectures are suitable for various use cases where responsiveness, scalability, and loose-coupling between components are important. Here are some main use cases for event-driven architectures:

1. Real-time Processing — EDA is well-suited for systems that require real-time processing of events, such as financial trading platforms, real-time analytics, and monitoring applications. Events trigger immediate responses, allowing systems to react quickly to changing conditions.
2. Microservices Architecture — Event-driven architectures align with the principles of microservices. Each microservice can independently produce and consume events, allowing for the creation of scalable, loosely coupled, and independently deployable services.
3. IoT (Internet of Things) — IoT applications often involve a large number of devices generating events, such as sensor readings or device status changes. EDA enables the efficient handling of these events, allowing systems to respond dynamically to the data generated by IoT devices.

Event Driven Architecture on AWS

Amazon Web Services (AWS) provides many managed services that support the implementation of event-driven architectures. Many of these services we will touch on within future posts within this Event Driven Series.

A lot of AWS EDA offerings that are fully or partly managed and maintained by AWS under the hood. AWS take care of all the infrastructure heavy lifting for us, such as reliability and fault tolerance, so that we can focus on the business value whilst delivering responsive and efficient applications.

Here are some AWS services that we’ll talk about later:

1. Amazon Simple Notification Service (SNS): Amazon SNS is a fully managed pub/sub messaging service that allows the decoupling of event producers and consumers. It enables the distribution of messages or events to a large number of subscribers through channels such as HTTP, email, and SQS (Simple Queue Service).
2. Amazon Simple Queue Service (SQS): Amazon SQS is a fully managed message queuing service that decouples services between your cloud architecture. It allows services to send messages and events to a queue, and other services can retrieve and process these asynchronously.
3. Amazon EventBridge: Amazon EventBridge is a serverless event bus that makes it easy to connect different applications using events. It supports the pub/sub model and integrates with a wide range of AWS services and third-party applications.
4. AWS Lambda: AWS Lambda is a serverless computing service that allows you to run code in response to events without provisioning or managing servers. With Lambda destinations, you can raise events on success or failure of the function.
5. AWS S3: AWS S3 is an massively scalable and elastic object storage service. The reason I list S3 here is that you can use S3 Event Notifications to kick start asynchronous event workflows.
6. Amazon DynamoDB Streams: DynamoDB Streams captures a time-ordered sequence of item-level updates in a DynamoDB table. It can be used to trigger AWS Lambda functions or other components in response to changes in the database.
7. Amazon Kinesis: Amazon Kinesis provides a set of services for real-time data streaming and analytics. Kinesis can be used for processing and analysing large volumes of streaming data.
8. Amazon CloudWatch Events: Amazon CloudWatch Events enables you to respond to system events and automate actions in your AWS environment. It supports rules that trigger based on events from various AWS services.

The beauty of AWS is these AWS services can be combined to create robust and scalable event-driven solutions on the cloud. As we will learn later, the choice of services depends on specific use cases, requirements, and the desired architecture of the application.

🌟 Summary

Today we’ve looked at the Event Driven Architecture (EDA) pattern at a high level and had a glance at how it can help us build enterprise applications in the cloud.

We’ve looked what an “event” means and later in the series we’ll be focusing on the anatomy of events and how we can use best practice to design these for flexible architecture in the cloud.

We also saw some examples of services that can hep us achieve event driven architectures on AWS and I can’t wait to get started showing you how to use these in more detail.

We have touched on how events can bring your business and technology departments together and we will later look at this in more detail. With harnessing the power of DDD we can aim to have a seamless IT department where all areas of the business contribute to building the right applications.

Please stay tuned for more Event Driven Architecture content. Like and subscribe to never miss a new post!

📣 Getting in touch!

Happy building!… 🚀 Thank you for reading

Hello I’m Robert Bulmer, a Technical Architect and Serverless Engineer with over five years of hands on experience in harnessing the capabilities of Amazon Web Services (AWS).

I am pleased to be an AWS Community Builder, in the Serverless domain, a community where I can connect and share with fellow advocates of cloud enthusiasts.

Read my Blogs at ArchiTech Insights

🔗 https://architechinsights.com/

Reach me on linkedIn here: https://www.linkedin.com/in/robertbulmer/

Disclaimer: The posts I write are designed to help the teams that I work with and echo my past experience in software development. My aim is to reduce the cognitive load on the teams so they can deliver maximum value to the business. While I hope this helps your journey, I accept no responsibility for your own use of the information.