Introduction
Event-driven architecture (EDA) is a modern architecture pattern built from small, decoupled services that publish, consume, or route events.
An event represents a change in state, or an update. For example: an item placed in a shopping cart, a file uploaded to a storage system, or an order becoming ready to ship. Events can either carry the state (such as the item name, price, or quantity in an order) or simply contain identifiers (for example, “order #8942 was shipped”) needed to look up related information.
Unlike traditional request-driven models, EDA promotes loose coupling between producer and consumer services. This makes it easier to scale, update, and independently deploy separate components of a system.
What is a decoupled architecture important?
Many organizations find that monolithic applications, databases, and technologies negatively impact innovation and improvement of the user experience. Legacy applications and databases reduce your options for adopting modern technology frameworks and constrain your competitiveness and innovation. However, when you modernize applications and their data stores, they become easier to scale and faster to develop.
A decoupled data strategy improves fault tolerance and resiliency, which helps accelerate the time to market (TTM) for your new application features.
Benefits of an event-driven architecture
Event-driven architecture (EDA) promotes loose coupling between components of a system, leading to greater agility. Microservices can scale independently, fail without impacting other services, and reduce the complexity of workflows. Events can be flexibly routed, buffered, and logged for auditing purposes. Push-based flows of events can operate in real time, cutting costs associated with creating and operating code that continuously polls systems for changes.
1. Scale and fail independently
By decoupling services, components in an event-driven architecture can scale and fail independently, increasing the resiliency of an application. This becomes increasingly important as the number of integrations between services grows. If one service has a failure, the rest can keep running.
Event-driven architecture can also make it easier to design near real-time systems, helping organizations move away from batch-based processing. Events are generated when an application state changes. As events scale up, so can the layer that processes the events.
Events are typically published to messaging services that behave like an elastic buffer between microservices and help handle scaling. Events might also be sent to a router service that can filter and route messages based on the content of the event. As a result, event-based applications can be more scalable and offer greater redundancy than monolithic applications.
2. Develop with agility
With event-driven architecture and event routers, developers no longer need to write custom code to poll, filter, and route events. An event router automatically filters and pushes events to consumers. The router also removes the need for heavy coordination between producer and consumer services, which increases developer agility.
Event-driven architecture is push-based, meaning that everything happens on demand as events are sent to the router and downstream systems, without needing to inform dependent services. Because of this, infrastructure and resources can scale up and down with event volume, which reduces costs to process workloads and operate deployed applications.
3. Build extensible systems
Event-driven architecture is also highly extensible. Other teams can extend features and add functionality without impacting the existing microservices. By publishing events, an application can integrate with existing systems—and future applications can integrate easily as event consumers—without changing the existing solution.
Event producers have no knowledge of event consumers, so extending the system has less friction, and new features or integrations do not add dependencies that slow down future development.
4. Reduce module complexity
Microservices enable developers and architects to decompose complex workflows. For example, they can break down an ecommerce monolith into order acceptance and payment processes with separate inventory, fulfillment, and accounting services.
A workload that might be complex to manage and orchestrate in a monolith becomes a series of simple, decoupled services that are managed independently and communicate asynchronously through event messages.
An event-driven approach makes it possible to assemble and orchestrate services that process data at different rates. In the following example, an order acceptance microservice interacts with a payment processing system via a queue.
How it works: example architecture
Here's an example of an event-driven architecture for an e-commerce site. This architecture enables the site to react to changes from a variety of sources during times of peak demand, without crashing the application or over-provisioning resources.
How does event-driven architecture (EDA) improve applications?
Event-driven architecture (EDA) promotes loose coupling between components, which makes it a good approach to build modern, distributed applications.
Event producers are unaware of, unconcerned by, and unburdened by any activity of downstream consumers of the events that they produce. The events themselves represent a change in state and may or may not contain data. Events are unaware of consequences of their existence. Consumers listen and process events of interest. You can bring new consumers online to provide new functionality without disrupting existing workflows.
EDAs promote decomposition of monolithic systems into smaller domain models. Developers can get up to speed with less cognitive load and become productive quicker. When critical functions are decoupled, there is also less risk to deploy updates and new features.
Top comments (0)