What is Event-Driven Architecture?
Event-driven architecture is defined as a software design pattern in which decoupled applications can asynchronously publish and subscribe to events via an event broker (modern messaging-oriented-middleware).
Event-driven architecture is a way of building enterprise IT systems that lets information flow between applications, microservices, and connected devices in a real-time manner as events occur throughout the business.
By introducing a middleman known as an event broker, event-driven architecture enables what’s called loose coupling of applications, meaning applications and devices don’t need to know where they are sending information, or where information they’re consuming comes from.
What is an “event” in context of EDA?
An event is a change of state, or more broadly anything that can be noticed and recorded by an application or device, and shared with other applications and devices. All of the things that happen within and to your enterprise are events – customer requests, inventory updates, sensor readings, etc.
Why use event-driven architecture?
The value of knowing about a given event, and being able to react to it, degrades over time. The more quickly you can get information about events where they need to be, the more effectively your business can react to opportunities to delight a customer, shift production, and re-allocate resources.
That’s why event-driven architecture, which pushes information as events happen, is a better architectural approach than waiting for systems to periodically poll for updates, as is the case with the API-led approach most companies take today.
Event-driven architecture ensures that when an event occurs, information about that event is sent to all of the systems and people that need it. It’s a simple concept, but these events have quite the journey. They need to efficiently move through a multitude of applications written in many different languages, using different APIs, leveraging different protocols, and arriving at many endpoints such as applications, analytics engines, and user interfaces.
If they don’t get there? Connected “things” can’t connect, the applications and systems you rely on fail, and people across your company can’t react to situations that need their attention.
What are the benefits of event-driven architecture?
The main benefits of event-driven architecture are the business outcomes that come from improved responsiveness, scalability, and agility. Being able to react to real-time information and being able to add new services and analytics quickly and easily, considerably enhances business processes and customer experience. Despite the fact that it can be costly to modernize IT infrastructure, 71% of businesses believe the benefits of event-driven architecture outweigh the costs.
Watch R “Ray” Wang, Founder, Chairman and Principal Analyst of a research and advisory firm which studying disruptive business technologies, take one minute to break down some benefits of event-driven architecture and why your business needs to be ready for it.
With event-driven architecture:
- Everything happens as soon as possible and nothing is waiting on anything else.
- You don’t have to consider what’s happening downstream, so you can add service instances to scale.
- Topic routing and filtering can divide up services quickly and easily – as in command query responsibility segregation.
- To add another service, you can just have it subscribe to an event and have it generate new events of its own – there’s no impact on existing services.
Naturally, when there are advantages to something, there are often disadvantages to go with it. We have compiled a Guide to Event-Driven Architecture Pros and Cons on our blog so you can weigh the pros and cons yourself.
Six + 1 Steps to Implement Event-Driven ArchitectureTo implement event-driven architecture, you need to have a good understanding of your data, but more importantly, you need to adopt an event-first mindset.
What are common use cases of event-driven architecture?
The benefits of event-driven architecture covered above are especially relevant in use cases where a single change can have huge consequences, rippling all the way down the chain. One of the most common questions people have is “When should you use event-driven architecture?” The answer lies in what you are trying to accomplish with your data.
Businesses looking to take advantage of real-time data in their daily activities are turning to event-driven architecture as the backbone for uses cases that can benefit the most. The top 4 use cases for event-driven architecture according to a 2021 survey were:
- Integrating applications
- Sharing and democratizing data across applications
- Connecting IoT devices for data ingestion/analytics
- Event-enabling microservices
It was found that 62% of businesses see real-time data distribution as beneficial for over 4 in 10 business operations. A number of areas where event-driven architecture and real-time data distribution has proven useful includes: COVID-19-related issues, data governance, and supply chain.
Who uses event-driven architecture?
By the middle of 2021, 13% of organizations had achieved full event-driven architecture maturity. Companies of all sizes all over the world use event-driven architecture to varying degrees, but here is a list of a few:
- HEINEKEN
- Schwarz Group
- Unilever
- Federal Aviation Administration
- RBC Capital Markets
Heineken recently moved to event-driven architecture as part of their long-term strategy to become the best connected brewer and to connect over 4,500 internal business-critical applications in areas like payments, logistics, inventory management, and more. With many acquisitions, Heineken was facing operations with legacy business systems and geographically dispersed sources of data relying on point-to-point communication with REST APIs. The move to an event-driven approach has resulted in much better burst management and less production interruptions, improving their overall efficiency.
Schwarz’s IT infrastructure has recently been updated to use an event-driven approach to modernize their supply chain and merchandise management systems so they could offer an omni-channel shopping experience to their customers. By replacing their legacy messaging middleware and using an event-driven architecture platform coupled with event-driven microservices, they are able to meet the requirements for independent scaling, accelerated deployment, and are in a great position to take advantage of cloud and IoT technologies.
Unilever, a British multinational consumer goods company, have transformed their technology backbone to event-driven architecture for a connected, agile, and responsive supply chain. Their Virtual Ocean Control Tower uses proactive real-time visibility and alerts to manage their logistics across 2,000 vessels, 400 ports, and 25 shipping lines. Unilever can now use real-time insights to evaluate and adjust as things happen instead of reacting to issues and chasing information.
The Federal Aviation Administration has modernized air traffic control with event-driven architecture to distribute real-time information to systems across the United States of America. Their System Wide Information Management (SWIM) system is built on a foundation of event brokers and ensures airlines and industry partners get the information in real-time without having to request updates.
RBC Capital Markets is among the top 10 investment banks in the world and was an early adopter of event-driven architecture over a decade ago. With over 50 event brokers acting as the message bus of their low latency trading platform, RBC Capital markets handles over 118 billion messages a day without any data loss. The ability to roll out new applications without any disruption across global systems, scale quickly and exponentially, as well as setting up a good foundation for a future hybrid-cloud solution are some of the benefits of event-driven architecture that have been mentioned by RBC’s Managing Director, Global Head of Architecture & Shared Application Services.
More Resources
- For more outcomes of businesses using event-driven architecture for their digital transformation projects, check out this post about Roche, TELUS Agriculture, Les Mousquetaires, and the University of California.
- A great resource for examples of other organizations using event-driven architecture as their IT infrastructure backbone are the EDA Summit videos that can be found on YouTube.
- Take an in-depth look at how event-driven architecture is trending in businesses globally with more statistics from the survey.
What are some examples of event-driven architecture?
The value of event-driven architecture transcends industries and can be applied to small businesses as well as large multinational corporations. Retailers and banks can use it to aggregate data from point of sale systems and across distribution networks to execute promotions, optimize inventory, and offer excellent customer service.
Retail and eCommerce Example of Event-Driven Architecture
This is an example of event-driven architecture from a retail perspective. Notice that no systems (inventory, finance, customer support) are polling to ask if there are any new events, they are simply filtered and routed in real-time to the services and applications that have registered their interest.
A stock inquiry instigated by a mobile application for the online store is only routed to the systems that might need to react to it – warehouse database and customer service. A new order placed on the point-of-sale system is shared only with the areas that have registered interest, in this case the finance system that need to register a sale as well as the warehouse data based that needs to update inventory numbers.
The Architect's Guide to Real-Time RetailThe 6 steps necessary to architect a scalable, real-time, event-based ecosystem for retailers expanding their global, multichannel footprint.
Retail Banking Example of Event-Driven Architecture
The key to meeting the needs of digital banking is establishing a continuous flow of information that spans the entire business, reaching to and from customers.
Event-driven architecture enables real-time communications between systems and services across environments and geographies, including branch transactions, lending systems, payment systems, account data, and more.
What are some common EDA concepts?
There are 8 key architectural concepts that need to be understood for event-driven architecture to be successful:
- Event broker
- Event portal
- Topics
- Event mesh
- Deferred execution
- Eventual consistency
- Choreography
- Command Query Responsibility Segregation
1. Event Broker
An event broker is middleware (which can be software, an appliance, or SaaS) that routes events between systems using the publish-subscribe messaging pattern. All applications connect to the event broker, which is responsible for accepting events from senders and delivering them to all systems subscribed to receive them.
It takes good system design and governance to ensure that events end up where they are needed, and effective communication between those sending events and those who need to respond. This is where tooling – such as an event portal – can help capture, communicate, document, and govern event-driven architecture.
2. Event Portal
As organizations look to adopt an event-driven architecture, many are finding it difficult to document the design process and understanding the impacts of changes to the system. Event portals let people design, create, discover, catalog, share, visualize, secure, and manage events and event-driven applications. Event portals serve three primary audiences:
- Architects use an event portal to define, discuss and review the events, data definitions, and application relationships.
- Developers use an event portal to discover, understand and reuse events across applications, lines of business and between external organizations.
- Data scientists use an event portal to understand event-driven data and discover new insights by combining events.
To learn more, follow this step-by-step guide to properly documenting your event-driven architecture to realize the full benefits of the pattern.
3. Topics
Events are tagged with metadata that describes the event, called a “topic.” A topic is a hierarchical text string that describes what’s in the event. Publishers just need to know what topic to send an event to, and the event broker takes care of delivery to systems that need it. Application register their interest in events with a given topic by subscribing to that topic. They can use wildcards to subscribe to a group of topics that have similar topic strings. By using the correct topic taxonomy and subscriptions, you can fulfill two rules of event-driven architecture:
- A subscriber should subscribe only to the events it needs. The subscription should do the filtering, not the business logic.
- A publisher should only send an event once, to one topic, and the event broker distributes it to any number of recipients.
Note: Always use topic hierarchy best practices to ensure these rules are obeyed.
4. Event Mesh
An event mesh is created and enabled through a network of interconnected event brokers. It’s a configurable and dynamic infrastructure layer for distributing events among decoupled applications, cloud services, and devices by dynamically routing events to any application no matter where these applications are deployed in the world, in any cloud, on-premises or IoT environment. Technically speaking, an event mesh is a network of interconnected event brokers that share consumer topic subscription information, and route messages amongst themselves so they can be passed along to subscribers.
5. Deferred Execution
If you’re used to REST-based APIs, the concept of deferred execution can be tricky to comprehend. The essence of event-driven architecture is that when you publish an event you don’t wait for a response. The event broker “holds” (persists) the event until all interested consumers accept/receive it, which may be some time later. Acting on the original event may then cause other events to be emitted, which are similarly persisted.
So event-driven architecture leads to cascades of events, which are temporally and functionally independent of each other, but caused in a sequence. All we know is that event A will at some point cause something to happen. The execution of the logic consuming event A isn’t necessarily instant – its execution is deferred.
6. Eventual Consistency
Following on from this idea of deferred execution – where you expect something to happen later, but don’t wait for it – is the idea of eventual consistency. Since you don’t know when an event will be consumed and you’re not waiting for confirmation, you can’t say with certainty that a given database has fully caught up with everything that needs to happen to it, and don’t know when that will be the case. If you have multiple stateful entities, (database, MDM, ERP) you can’t say they will have exactly the same state – you can’t assume they are consistent. However, for a given object we know that it will become consistent eventually.
7. Choreography
Deferred execution and eventual consistency lead us to the concept of choreography. To coordinate a sequence of actions being taken by different services, you could choose to introduce a master service dedicated to keeping track of all the other services, taking action if there’s an error. This approach, called orchestration, offers a single point of reference when tracing a problem, but also a single point of failure and a bottleneck.
With event-driven architecture, services are relied upon to understand what to do with an incoming event, frequently generating new events. This leads to a “dance” of individual services doing their own things, but when combined, producing an implicitly coordinated response – hence the term choreography. The blog post Microservices Choreography vs Orchestration: The Benefits of Choreography talks about the concept in detail.
8. CQRS – Command Query Responsibility Segregation
A common way of scaling microservices is to separate the service responsible for doing something (command) and the service responsible for answering queries. Typically, you have to answer many more queries than for an update or insert, so separating responsibilities this way makes scaling the query service easier.
Using event-driven architecture makes this easy since the topic should contain the verb – so you simply create more instances of the query service and have it listen to the topics with the query verb.
The 6 Principles of Event-Driven Architecture
There we have it, some main principles of event-driven architecture:
- Use a network of event brokers to make sure the right “things” get the right events.
- Use topics to make sure you only send once and only receive what you need.
- Use an event portal to design, document, and govern event-driven architecture across internal and external teams.
- Use event broker persistence to allow consumers to process events when they’re ready (deferred execution).
- Remember this means not everything is up to date (eventual consistency).
- Use topics again to separate out different parts of a service (command query responsibility segregation).