4 event-driven architecture use cases (with examples)

Event-driven architecture, also called EDA, is a model of software architecture design that prioritizes the flow of events through an application. 

In traditional architecture design – typically known as request/response – application components are prioritized and events are secondary. In these systems, application components request updates and wait for a response from the components they’re calling. 

In many contexts, these delays are fine. Most data doesn’t need to be realtime and until relatively recently, companies didn’t have to face such stringent demands for scalability and reliability. But now, with the rise of realtime data and the ever-increasing need for globally available applications, EDA is poised to rise in popularity.

In EDA designs, events drive application functionality and initiate the processes and connections between application components. EDA introduces a middleware component – called a broker – that facilitates the passage of events between application components. One component, a subscriber, can subscribe to an event flow, and another component, a publisher, creates events that the broker can pass to the event flow. 

The primary benefits of this design structure are increased scalability, improved reliability, and the ability to use realtime data. By decoupling publishers and subscribers, applications backed by an EDA design can have greater flexibility, making it easier to scale, and by making the flow of events faster, realtime data features can function better.

EDA is best understood through use cases and examples because the benefits are compelling but the tradeoffs of adopting EDA – primarily overhead from its complexity – are not always worthwhile without the right use case.

Microservices, similar to EDA, pose a dramatic architecture-level change to traditional software systems. In the past, all applications were housed as monoliths – meaning all the code comprised a single unit. 

But in the mid-2010s, thanks to innovation from companies like Netflix and Amazon, a new model emerged – microservices. In a microservices design, applications are broken down into separate isolated services interconnected via API. 

With EDA, companies can achieve even deeper levels of decoupling than with microservices alone. Companies can capture events without having to require all downstream components to synchronously accept those events. As a result, systems become scalable and more reliable all while remaining decoupled. 

When a user performs an action – clicking a button or loading a new page, for example – a request/response system commits that event to a database only after the downstream processes are complete. An EDA system instead captures the event and processes it via the next component in the workflow as soon as possible. 

Even in moments of high data load or extreme usage fluctuation, EDA systems can capture events immediately and guarantee that they’ll be processed – even if the system has to wait for downstream processes to catch up.

With the support of EDA, microservices systems can more efficiently share information amongst decoupled services – especially at scale. One of the best benefits of this combination is the removal of temporal coupling, resulting in internal systems that don’t require all services to be available at the same time for processes to run.

An ecommerce company, for example, will likely have sales, billing, and warehousing services that need to connect and work in conjunction. When an order is placed, the sales service will need to call the billing service to charge the customer who made the order and the billing service will need to call the manufacturing service to fulfill the order. 

In a request/response system, a failed call to the warehousing service might mean the customer gets charged anyway. In an EDA system, a broker removes temporal coupling and ensures each service can operate independently. If a customer makes an order and the billing service fails, the system can continue running without error. Once the billing service is available again, it can capture the order event from the broker and run as though nothing happened.

Even some of the companies that have adopted EDA systems haven’t realized their full potential. In many EDA implementations, the focus of the design is on facilitating the communication of events from internal service to internal service. 

But with a data broadcasting solution like Ably, you can broadcast those events to customers too – all the while maintaining the stringent reliability and integrity demands necessary for customer-facing applications. 

With EDA, enterprise systems can be much more scalable and reliable, meaning applications with broadcast features can more easily achieve global availability while relying on the more efficient processing of events. Companies can make their distributed systems more efficient and connect that work back to their customers, ensuring the efficiency gains pay off in ways both visible and invisible to customers.

When a customer offers a company their credit card only for the payment to fail, frustration and confusion are likely. Where does the problem lie? Is it the card? The payment portal? The company the customer is ordering from? Something else in between all of these processes?

It’s a moment that can turn an opportunity for delight – getting a new product – into a moment of stress. Many ecommerce companies take this problem seriously but without a full implementation of EDA, resolving the problem is difficult. 

In a request/response system, the burden is on the client to request application components for state changes and updates. But if there’s a payment transaction failure, the inherent delay this system incurs becomes a business-critical concern. 

With EDA, companies can connect their internal event-driven systems to customer-facing update functions. If a payment fails, the system can react by making sure the order doesn’t trigger fulfillment or inventory processes, and the system can ensure the customer instantly knows what went wrong and why.

As soon as the payment fails, an event streaming platform like Kafka can capture the event, process it, and add a success/failure response to an event queue. The system can then capture the success events and commit them to a database. Meanwhile, failure events can flow through a platform like Ably so they can be broadcasted to customers.

Many businesses succeed or struggle based on how well they can capture, analyze, and react to data. Consumers are increasingly demanding faster deliveries, always-available applications, and interactive experiences that are as responsive as they are engaging. 

With EDA, companies building applications with realtime data analysis features can better support those features with the greater responsiveness an EDA system provides. Because events drive processes in an EDA system, the passage of data tends to be faster, meaning data can hit analysis tools sooner and analysis can begin earlier. 

With the addition of event sourcing – a design pattern that enables the storage of events and the context of those events – EDA can also provide more meaning than would otherwise be available. Event streaming platforms like Kafka, for example, allow companies to connect different services across distributed systems while facilitating the communication of events. Companies can build decoupled, scalable systems with high integrity even as they stream events – and the contextual information surrounding them – from one system to another.

The logistics industry, including major companies like UPS and DHL as well as a multitude of smaller specialty companies and contractors, has the hard job of moving an endless variety of packages across the world. But they also have to monitor the journeys of those packages, analyze their movements, and keep customers informed. 

EDA can help by supporting dashboards that provide realtime data monitoring and analysis. With these dashboards, logistics companies can keep a closer eye on the web of processes that keep packages moving. And with event streaming platforms in conjunction, these dashboards can ingest and display events as well as the contexts that produced these events. 

In a request/response system, application components are often stuck in a holding pattern – waiting for a response. But with an EDA system, a logistics company can build more efficient ways of processing and transmitting data – all without incurring request/response delays.

Read more about how transport and logistics companies can support realtime updates.

IoT hype peaked in 2014 but in the years after, use cases have proliferated and the technology – albeit more quietly than before – has become essential to many companies. Some of the best IoT use cases, it turns out, don’t involve end-users requesting deliveries from an Amazon Alexa device but involve companies using IoT devices on edge networks to monitor supply chains. 

The advantages of using IoT devices in these contexts are significant. With devices in use and data analyzed, companies can better ensure the integrity of any given shipment and can also improve the integrity of their supply chains over time. 

With EDA, the events each IoT device publishes can be near-instantly captured by subscribing components. One IoT device can be on a shipping container on an edge network somewhere distant in the world but with EDA, multiple subscribers can clue into the event flow and get rapid updates. 

The shipping industry provides some of the best examples of the use cases for both IoT and EDA. 

The benefits of EDA aren’t as visible if you only think about an Amazon warehouse receiving an order from a customer and shipping it directly to them. The greater benefits lie in companies managing much larger and more complex supply chains. Device manufacturers, for example, often have to manage the shipment, delivery, and assembly of dozens of parts across numerous countries to build modern phones. 

With EDA, the entire web becomes seamless, and communication amongst its many nodes becomes more efficient. Even if the event publisher is an IoT device embedded in the wall of a shipping container somewhere out on the ocean, a shipping company can still capture and transmit event updates almost instantaneously.

Enterprises considering EDA will make the most informed decision by considering the use cases above and by weighing the benefits of EDA against its challenges. 

EDA is especially compelling for enterprises with significant scalability needs. EDA decouples publishers and subscribers, meaning that development teams can allocate additional resources only to components dealing with increased data load or traffic.

With EDA, enterprises can create loose coupling between components so that when one component fails, the rest of the system can keep running. Since EDA offers asynchronous communication, each subscriber component is free to keep running despite how the publisher component is working (or not working). 

IDC research shows that by 2025, almost 30% of data will be realtime. Realtime data – to fulfill the promise of being truly realtime – needs to be transmitted at a speed that feels instantaneous to end users. But as hard as this already is, ensuring realtime updates across globally distributed users reliably and accurately is even harder. But with EDA systems, companies can build realtime updates infrastructure that is better able to efficiently process and transmit events. 

Read more about the benefits of EDA.

EDA systems are often most beneficial to enterprises with large, complex codebases because EDA itself tends to be complex and resource intensive. For small development teams, the complexity can be daunting, and the overhead overwhelming. Request/response systems, in contrast, tend to be simpler and for most developers, more familiar and easy to use. 

Sometimes, businesses are drawn to EDA systems for too few use cases – even if those reasons are individually compelling. Due to the complexity and overhead mentioned above, even the presence of a couple of good use cases can mean EDA systems are still too burdensome. This is especially true for tasks that are merely periodic, such as regular cron jobs. Even though EDA could technically make these processes faster, it’s still often best to run these processes in the background rather than trying to speed them up at an architectural level. 

EDA, similar to realtime updates infrastructure, is only beneficial after an effective implementation. Companies often adopt EDA when they need greater scalability or resiliency, but poor implementations of EDA can make both aspects worse than before. EDA is also hard to maintain because there’s a lack of external support for event-driven protocols and because there’s less familiarity with EDA systems amongst developers typically familiar with request/response systems.

Read more about the challenges of event-driven architecture and how to overcome them.

EDA systems have enormous benefits but the complexity of the system – as well as the effort it takes to overhaul an application – means the benefits are likely outweighed by the tradeoffs without the right use cases. 

But enterprises with use cases that suit EDA will be well-positioned both for short and long-term innovation if they make EDA adoption a priority. With loose coupling and greater scalability, amongst its other benefits, EDA can make use cases ranging from IoT device monitoring to microservices coordination significantly more effective. Companies still running request/response systems will struggle to keep up due to architecture-level limitations and forward-thinking companies will be able to outpace the rest.

To learn more about EDA, read our guide to EDA or more detailed exploration of EDA patterns and when to use them.