Event-Driven Architectures on AWS

In this post we’ll go through the main components of an event-driven architecture and explore AWS services that fit in event-driven architectures.

What is it?

Event-driven architecture (EDA) represents a system of loosely coupled components that exchange information between each other asynchronously through events. An event represents a change in state (e.g. registration form is submitted, booking has been made).

In traditional request-response architectures, the sender sends a request and waits for the response prior moving to the next task. Additionally, both the sender and the receiver are directly impacted by any failures that occur on any side, e.g. if there is a failure at the receiver the sender has no option of how to communicate and send the request.

In event-driven architecture, the component that generates an event can immediately proceed with its next task. Then different components of the system can react to the emitted event.

How does it work?

Event-driven architecture is based on asynchronous communication between system components via events. The event is immutable, meaning the event cannot be changed after its creation. Each time there is a change in an entity’s state, a new event is generated. With the immutable events in a distributed system there are no changes across components to keep in sync. Events are observed, not directed. A component that emits an event has no particular destination nor awareness of downstream components that may consume the event.

Event-driven architecture consists of event producers, event routers and event consumers:

• Event producers publish events to a router.

• Event brokers mediate between producers and consumers.

• Event consumers are downstream components that react to events.

The event broker receives events, stores them in a queue or event stream and provides them for consumption to other system components.

Producers and consumers are decoupled, which allows them to be scaled, updated and deployed independently. The producer is not aware which consumers, if any, are listening for the events. The consumers can process the event on their own schedule. The consumers are also decoupled from each other and every consumer sees all the events. This is in contrast to message-driven architecture where a message is intended for one consumer and deleted after it is being consumed.

Event-driven architectures on AWS

At the core of every event-driven architecture is the event broker, which can be an event router or an event stream. For event routers there are two main types: event buses and event topics. In AWS, these components are represented by Amazon Event Bridge as event bus and Amazon Simple Notification Service (SNS) as event topic.

EventBridge is an event bus service. It applies rules to route events from event sources to different targets. Targets can include AWS services such as AWS Lambda, Step Functions, and Amazon Kinesis, or any HTTP endpoint through EventBridge API destinations.

SNS is a service that enables publishing messages from an application and immediately delivers them to subscribers or other applications. Publishers communicate asynchronously with subscribers by sending messages to a topic, which is a logical access point and communication channel. Clients can subscribe to the SNS topic and receive published messages.

For event streaming, Amazon Kinesis Data Streams can be used as an event-streaming service. It is a highly scalable service that allows multiple consumers reading from the stream and provides batch processing instead of an individual event at a time.

Here you can find more details on event-driven architectures, event-driven architectures in serverless applications, building event-driven microservices and benefits of migrating to event-driven architecture.