Benefits of EDA
An EDA brings several benefits to your application when compared to an application that uses only synchronous or point-to-point (P2P) communication patterns.
Resiliency
In a P2P connection as shown in the following diagram, the calling component, Orders, is dependent on the called component, Depot, being available. If the called component cannot process the operation in time, or if the called component has a fault, then that error will propagate back to the caller. Worse is a chain or tree of calls that end up with a fault somewhere far away from the original caller, causing the entire operation to fail.
If the Depot service is not responding or is failing to respond on time, then the Orders service may fail to pass on information regarding new orders:
Figure 1.10 – P2P communication
In an EDA application, the components have been loosely coupled and will be set up with an event broker between them, as shown in the following diagram. A crash in an event consumer will have no impact on the event producer. Likewise, other faults (internal to the consumer) that cause it to temporarily be unable to process events again have no impact:
Figure 1.11 – Brokered event communication
Considering the example case of the Depot service becoming overrun with work, causing it to get backed up, orders submitted by the Orders service will be processed, just a little slower. The Orders service will be unaffected and continue to take orders as they come in. Better still, if the Depot service is down entirely, then it may only cause a longer delay until it can be restarted or replaced, and the Orders service continues.
Agility
An event-driven application can be more agile in its development. Less coordination between teams is required when introducing new components to an application. The new feature team may drop in the new component without having to socialize any new API with any of the other teams.
The organization can more easily experiment with new features as an aside. A small team can stand up a new component without disrupting the work of other teams or the flow of existing processes. When the experiment is over, the team can just as easily remove the component from the application.
We can imagine that, at some point, an Analytics service could be introduced to the application. There are two ways this new service could be added. The first way is with a synchronous API (as shown in Figure 1.12) and the second is with an asynchronous event consumer (as shown in Figure 1.13).
When they choose to use the API, the team will need to coordinate with existing teams to potentially add new logic to capture data and new calls to their service. Completing this task will now require scheduling with one or more teams and will become dependent on them, as illustrated in the following diagram:
Figure 1.12 – New P2P service
Components that communicate using events make it easier for new components and processes to come online without requiring coordination with the teams in charge of existing components, as shown in the following diagram:
Figure 1.13 – New brokered event service
Now, when the Analytics service team has finished its work of picking which events to consume and captures the data that it needs, it can then add it to the application immediately.
If event streams are part of your EDA application, this also has the advantage of providing new components with a complete history of events to spin up with.
User experience (UX)
With Internet of Things (IoT) devices exploding in number and millions of people having phones in their hands, users expect to be notified of the latest news and events the instant they happen. An event-driven application is already sending updates for orders, shipment notifications, and more. The organization may extend this to users more easily than a traditional synchronous-first application might allow.
Analytics and auditing
Whether you’re using event notifications, event-carried state transfer, or event sourcing, you will have ample opportunity to plug in auditing for the small changes that occur in your system. Likewise, if you’re interested in building on analytics to your application to gather business intelligence (BI) for your marketing and product teams, often one or both are an afterthought, and in a traditional or non-EDA application, you may not have the data or can only recreate a partial picture.