You may have heard many technical benefits of Event-Driven Architecture (EDA) — it’s highly responsive and can help “unlock data.” But, how exactly can EDA improve the bottom line? That’s what we’ll discuss below by diving into four of the most significant end business benefits of an event-driven architecture. To help us along the way, we’ll discuss each benefit in the context of the same example scenario: an eCommerce application.

1. Efficient Development

Using an event-driven architecture can significantly improve developmental efficiency in terms of both speed and cost. This is because all events are passed through a central event bus, which new services can easily connect with. Not only can services listen for specific events, triggering new code where appropriate, but they can also push events of their own to the event bus, indirectly connecting to existing services.

From a development standpoint, this is far more efficient (at least at scale) than building point-to-point integrations. Admittedly, an event-driven architecture may seem more complicated to begin with — since most processes will have to start and end with some kind of event — but once your application is up and running, it’ll be much easier to add to this than a traditional monolith.

Our Example

In our example scenario of an eCommerce app, let’s assume that order shipments are registered manually. We now want to develop a process that will register these shipments automatically, using postal carriers’ APIs.

With an event-driven architecture, all we need to do is create a standalone service that listens for order-created events. Then, the service can use postal carriers’ API to register the shipment and retrieve a tracking number. Finally, the service can publish an order updated event containing the tracking number. With any luck, there is already a notification service that listens for order update events that’ll forward the tracking number to customers!

2. Better User Experience

If you want to increase the retention and lifetime value of customers, improving your application’s user experience is a must. An event-driven architecture can be incredibly beneficial to user experience (albeit indirectly) since it encourages you to think about and build around… events!

For the user in an increasingly digital world, event-driven behavior and real-time responsiveness are becoming an expectation. What with smartphones, users expect an email or push notification when events take place, both in personal and professional contexts. Machine-to-human communication is the more relatable aspect of this, but as machine-to-machine communication becomes more prominent — what with APIs and IoT — an event-driven architecture will also make it easier to interact with third-party services, providing a fuller, stickier user experience.

“Developers need to be able to quickly and consistently create event-driven applications that provide business value and react to customer needs in real-time.” – Jonathan Schabowsky, Sr. Architect at Solace

Our Example

Let’s return to our hypothetical eCommerce app. Here, an event-driven architecture in conjunction with an event-driven notification service really augments the user experience. So long as we diligently update the event bus, the customer will always be up-to-date with their orders. For instance, if an ordered product is actually out of stock, employees can be trained to mark this in a web interface that broadcasts to the event bus. Thanks to the notification service, the user will automatically receive a message about their order.

As for the machine-to-machine aspect, consider the shipment registration service described previously. Since shipment registration is event-driven, the postal carrier is updated in real-time. As a result, the customer can continue tracking their order through the carrier’s channels without any gap or delay.

3. Lower Running Costs

Using an event-driven architecture can also reduce the running costs of your application. Since events are pushed to services as they happen, there’s no need for services to poll each other for state changes continuously. This leads to significantly fewer calls being made, which reduces bandwidth consumption and CPU usage, ultimately translating to lower operating costs. Additionally, those using a third-party API gateway or proxy will pay less if they are billed per-call.

Our Example

Let’s assume our eCommerce app has its own payment processing service. With an event-driven architecture, that service can push out an order paid event when payment has been finalized, automatically updating other parts of the application. This way, there’s no need to poll the payment status of every order every few seconds.

It may not matter much for a startup eCommerce site, but eCommerce payments are incredibly demanding at an enterprise scale. Regardless, the point still stands: an event-driven architecture leads to fewer calls, which ultimately leads to lower running costs (proportionally to the throughput of the application).

4. Resiliency

Last but not least, an event-driven architecture can make your application more resilient. If a service fails, it can automatically restart and replay events from the event bus. After doing so, it can update other services by pushing events of its own to the stream. Sure, there may be some delays, but that’s still better than the application not responding to an event at all, as could be the case with other architectures.

There is another side to the resiliency aspect of event-driven architectures, and that lies in the fact that individual services are very loosely coupled. Since services do not communicate with one another directly — but by means of an event bus — one service failing does not necessarily mean others will too.

“In a synchronous model, a service must be available and responsive in order to communicate. When a service is not available, the entire system can stall or even break down… With event-driven architectures, events do not require a reply and are inherently asynchronous, which means events can be consumed and processed later, if a service is busy or unavailable.” – Sameer Parulkar, Product Marketing Director at RedHat.com

Our Example

For this last example, let’s once again look at the automatic shipment registration service that our event-driven architecture enabled. Suppose this service crashes and only restarts half an hour later. Despite the crash, it can replay all the new orders from the event bus, register all shipments one-by-one, and broadcast order updates with the tracking numbers.

Indeed, this would lead to a thirty-minute delay in every customer receiving their shipping information. However, the shipments would still be registered with no lasting damage or confusion caused. Additionally, no other services should have been affected: order creation, payment processing, and most notifications are likely to have functioned as intended.

Summary

There’s a lot to like about event-driven architectures, especially in this increasingly responsive digital landscape. From a business perspective, executives can expect faster and cheaper development, an improved user experience, lower running costs, and increased resiliency when buying into an event-driven architecture. With any luck, our eCommerce example illustrates how these business benefits arise!