What Is Event-Driven Architecture? Everything You Need to Know

Event-driven architecture may seem like an abstract concept, but its foundation is very simple. Let's consider a simple example. You're at a stoplight. The light turns green (the event), so you drive forward (the reaction).

Get Started with HubSpot's Analytics Software for Free

Until the traffic light signaled it was okay to proceed, you did not react. Your reaction is dictated by logic: traffic laws, your destination, traffic conditions ahead of your car. This is the essence of an event-driven system.

So, what is event-driven architecture? To answer this question, we must first understand events.

What does it mean to be event driven?

Events are actions. Whenever something happens inside or outside your organization, an event has occurred. These actions can be anything: a customer purchase, an inventory update in a warehouse, an attempted security breach, a change in state for an application, the list goes on.

Many events are time-sensitive or mission-critical, so companies want to build their infrastructure around capturing and reacting to these events. A business is event-driven when events trigger reactions within the organization. In the digital age, events are handled by IT systems that record, process, and respond to events based on preset logic.

Events in system design share common characteristics:

• They are a record that something has happened.
• They are immutable — they can't be changed or deleted.
• They can be persisted indefinitely — events can be stored and accessed forever.
• They can be consumed an unlimited number of times — there is no limit to the number of times an event can be processed by a service.

It's important to note that an event is simply an action. Event-driven architectures handle event notifications — an event notification is a message confirming an action has been taken. The notification may be a simple confirmation of the action or contain additional data about the event that downstream systems use to apply their business logic.

For example, a purchase notification can include the customer's ID, product ID, purchase total, purchase date and time, and other metrics that a CRM uses to create a profile of the customer and predict future products they might need.

Because it's the event notification or message that's being handled in the system, event-driven architecture is sometimes referred to as message-driven architecture.

Now that we understand events, we’re better prepared to answer the main question:

What is event-driven architecture?

Event-driven architecture (EDA) is a system design practice built to record, transmit, and process events through a decoupled architecture. This means that systems don't need to know about each other to share information and accomplish tasks.

Decoupling is a central component of EDA, and it offers a major advantage versus other methods for sharing data such as APIs. When sending an API call, the application needs to know the dependencies and parameters so it can send a properly formatted request. It then waits for the response before proceeding. This also means that there will always be a request and a response to transfer data.

With decoupling, an event producer sends its notification without needing to know what happens after, leaving it to the event router — also known as a broker — to decide where it goes. You can think of an event router like a WiFi router; it receives data from the internet and distributes it to the different devices that need it in real time. Consumers — also known as sinks — receive the event to process without needing to request it. Every service that consumes the event works on its own, meaning that events are processed asynchronously.

Image Source

The flow of event data between the event producers, event router, and event consumers is known as an event channel.

This video from A Dev Story reviews event-driven architecture and its benefits and challenges (which are covered in later sections):

To fully understand this concept, let's examine some use cases and an example of EDA in action over the following sections.

Event-Driven Architecture Use Cases

Organizations leverage EDA when designing their systems to achieve many different use cases. The following are the most common:

• Data replication: One event can be shared between multiple services that need to copy its data into their databases.
• Parallel processing: Multiple processes can be triggered by one event to execute asynchronously of each other.
• Real-time monitoring: Systems can generate events for changes to their state so an organization can scan for anomalies and suspicious activities.
• Interoperability: Events can be persisted and propagated regardless of the code services are written in.
• Redundancy: If a service is down, events can be persisted in the router until the service is available to consume the event.
• Microservices: EDA is commonly paired with microservices to efficiently share information between decoupled systems at scale.

Now let's look at an example of EDA in action.

Event-Driven Architecture Example

To review, events are actions, and EDA is how an organization defines the reaction to the event.

For our example, let’s look at how an online store might adopt an event-driven architecture. On an eCommerce site, a customer submitting payment information is a common and critical action. The UI generates the “Payment Submitted” event with credit card details, and the event router knows to route the notification to the payment system based on the event's metadata.

Once the notification is received, the payment system processes the event and generates a new “Payment Processed” event indicating success or failure. The event router pushes this back to the website UI, which shows the status to the customer and prompts next steps. If payment has failed, the UI can reopen the form to update the details. If payment succeeded, the UI can display final order details and expected delivery date, for example.

Image Source

The architecture works in this example because the event router is configured to facilitate the flow of information. Neither the front-end website nor the back-end services know their counterparts exist. They are simply subscribed to “Payment Submitted” and “Payment Processed” events, and the event router maintains these event channels.

This video provides another example of EDA in action for a healthcare system and uses this scenario to review EDA's components:

Event-Driven Architecture Patterns

An EDA pattern designates how event producers, routers, and consumers work together. There are two common patterns in EDA architecture: publisher/subscriber and event streaming. The following sections expand on both these designs.

Publisher/Subscriber Architecture

In a publisher/subscriber architecture (sometimes shortened to pub/sub), the event router tracks subscriptions from consumers to event channels. When an event is published, the router ensures the subscriber receives it.

Image Source

Events can't be replayed, so if a subscriber joins an event stream after an event is generated, they can't retroactively access it. The consumer will receive new events from that point forward.

Event Streaming Architecture

Event streaming moves past the subscription-based pattern. In this approach, events are written to a log, and all consumers can read the log to identify relevant events. Consumers can read from any part of the stream, so they can replay past events.

Image Source

Event Processing Patterns

In addition to different models, there are also unique approaches to processing the events once they reach a consumer.

• Simple event processing: Consumers process each event as it is received, such as in the previous eCommerce site example.
• Complex event processing: Consumers process a series of events to detect patterns in the event data.
• Event stream processing: Data streaming platforms ingest events and create a pipeline to stream processors that transform and consume the data.

This video from CodeOpinion reviews some advanced EDA models:

Benefits of Event-Driven Architecture

EDA offers many benefits for organizations seeking to improve the responsiveness and flexibility of their tech stack.

Decoupling

Services no longer need to know other services exist to work together. They only need to know about events, and the broker delegates the right events to the right systems. Decoupling makes EDA a natural fit for connecting microservices.

Immutability

Events can't be changed once created, so they can be shared with multiple services without the risk of one service modifying or removing information that other services would then consume.

Persistability

In traditional models, if Service 2 is down, then Service 1's request to Service 2 will bounce, causing errors. With events, the broker can persist the event until Service 2 is back online to receive the event. This avoids a single point of failure and improves durability.

Scalability

One event can be used to trigger multiple actions in different consumers, enabling parallel task execution and improving performance. Decoupling also simplifies the process to stand up, update, or remove event producers and consumers because you don't need to update the logic in each service or system, allowing you to quickly adjust your toolstack to meet new requirements or demand.

Real-time Workflows

EDA executes as events occur, supporting real-time or near real-time responses to mission-critical interactions like purchases and live chat messages. This agility ensures that customers are always provided with the support and information as soon as they need it.

Simplified Auditing

The event router's role as middleware for the flow of information simplifies the auditing and compliance process. You can set permissions for data access from this central point for the entire organization. Plus, because events are immutable, their data can never be modified or removed, creating a reliable audit trail.

Challenges of Event-Driven Architecture

Though EDA offers many advantages, some of these gains come with tradeoffs, including the following.

Performance

Because there's a "middle man" between producers and consumers, this may lead to performance decreases versus a direct pathway between services. This means it may take longer for consumers to execute actions because they aren't receiving the event as quickly.

There are also tradeoffs between moving events with all available data or sending slimmer notifications that then require the consumers to query for additional data. On the one hand, event transmission will take longer and not every consumer may need the full data set. On the other hand, you will need to define additional logic to ensure the consumer procures any missing data.

Eventual Consistency

Two services may process and react to an event at different times based on how long it takes to execute their tasks and other factors. This means that not all reactions to an event will occur at the same time, but eventually all services will have finished processing the event. This effect is known as eventual consistency.

Complexity

Decoupling removes the need for dependency tracking and other obstacles that typically impede a microservices architecture. However, the tradeoff of independent services is that it is now more challenging to track the status of events between multiple applications versus direct dependencies where the relationships are more defined.

Event-driven architecture powers agile businesses.

EDA is a powerful approach to system design that introduces new efficiencies and flexibility for organizations looking to quickly address the events that matter to their business. It enables parallel execution, data replication, interoperability, and other use cases with ease. EDA is a central method for achieving an event-driven organization where actions trigger immediate responses, increasing agility and scaling to meet customer needs.