Event Driven Architecture in Web Development

The web application reports on its own. And to provide this service, a service must run continuously and reliably. Best practices to achieve high availability resort to multiple execution up to redundant data center execution. Apart from the fact that in many cases this is not an option anyway, there still follows the challenge of minimizing deviations and knowing where the truth lies if the worst comes to the worst. But there is a methodology that promises to help.

What is Event Driven Architecture (EDA) and how does this help my business?

In an EDA or event driven architecture, the interaction of components is driven by events. Everything that happens in the enterprise (or the enterprise logic within the software) is an "event" - customer requests, changes in inventory levels, receipt of readings from sensors, in fact anything that cannot be planned. The earlier the organization knows about events, and that exactly at the point where they are relevant, the more effectively it can react - thereby satisfying a customer, adjusting production figures, allocating resources where the need is now greatest.

Therefore, Event Driven Architecture, which relays events as they occur, is a better architecture than solutions that periodically or user-driven check for updates. It sounds like a simple concept, but these events have a lot to deal with, they need to be available across applications to different users and systems.

EDA delivers the solution with a kind of middleman, called an event broker. Individual components now no longer know who all gets your information, or where a received event originates. They know the Event Broker and receive, if at all, from it a notice about a sent event. This finally makes EDA a good architecture - there are no dependencies between the sender and receivers of an event. It is obvious that the setting up of an Event Broker in conformity with the requirements and the interaction with the components is sensibly accompanied by an experienced service provider.

Example: Practical requirements in logistics and supply chains

Logistics and supply chains are typically business areas with many different players from different companies. For example: Goods from a manufacturer are delivered to a central warehouse via different transport routes. The same goods are picked up by different carriers and delivered to different stores.

Orders, deliveries, schedules, invoices already provide a complex field of requirements, plus payment transactions via different financial service providers. On the other hand, there is a user with needs and purchasing power - who wants to know via a web application whether an item is available in the outlet of his choice, perhaps reserve it or order it online and have it delivered to his home. The web application should offer him a cost comparison of both options and, in the case of an online order, the expected delivery date. Depending on the size of the goods, a trailer can be rented. If all the information is available, the decision on which way to purchase the item follows. However, if information is missing, the next supplier is chosen.

Solution with Event Driven Architecture for your competitive advantage

In the practical example of a purchase decision via a web application, the requirements become clear. The path to implementation with Event Driven Architecture leads, among other things, through the triggering events, the setting up of an Event Manager and the provision of components which recognize events of interest to them in order to react to them. Where to start? The first step is a free initial consultation to clarify expectations and outline a possible roadmap to implementation.

Sources

https://stackoverflow.blog/2020/03/16/how-event-driven-architecture-solves-modern-web-app-problems/

https://de.wikipedia.org/wiki/Ereignisgesteuerte_Architektur

https://solace.com/what-is-event-driven-architecture/

https://turvo.com/articles/architecture-for-large-scale-supply-chain/