Why Event-Driven Architecture (EDA) is needed?
In today’s world application programming interfaces (APIs) are driving digital transformation and leading the IT environments across the industry. It has raised high expectations of end-users who now expect digital experiences to be interactive, responsive, and immediate. APIs are now used for various purposes such as creating a superior user experience across Omni-channels, exposing business as a service, and business-to-business interactions.
In order to design scalable solutions, APIs are designed using event-driven architecture (EDA) in tandem with service-oriented architectures. EDA enables loosely coupled, fault-tolerant, and cost-effective architecture.
There are various ways to implement the EDA, some of them are namely Command and Query Responsibility Segregation (CQRS), Pub-Sub, SAGA, 2/3Phase Commits. In fact, most cloud providers have built accelerators and PoVs to provide guidance around EDA. Some of these examples are:
Amazon Web Services (AWS) - recommends utilizing Event Bridge decoupled event-driven architecture. Below is the snippet of the architecture which enables the site to react to changes from a variety of sources during times of peak demand, without crashing the application or over-provisioning resources.
Google (GCP)- recommends using event producers, event routers, triggers, and event consumers. In their recommended architecture, events are generated by event producers, ingested and filtered by an event router (or broker), and then fanned out to the appropriate event consumers (or sinks). The events are forwarded to subscribers defined by one or more matching triggers. These three components — event producers, event router, event consumers — are decoupled and can be independently deployed, updated, and scaled:
Azure- also recommends leveraging loosely coupled EDA architecture which consists of event producers that generate a stream of events, and event consumers that listen for the events. Events are delivered in near real-time, so consumers can respond immediately to events as they occur. Producers are decoupled from consumers — a producer doesn’t know which consumers are listening
Custom Solution for EDA- Below snippet is another example of implementing EDA using the SAGA pattern which leverages message broker and 3 layer API strategy. Consumer applications can call the experience API which enables calls to the process API and then the message broker manages end-to-end event choreography including transformations. It also ensures eventual consistency.
Additionally, in Open-Source tooling, AsyncAPI is also helping to easily build and maintain event-driven architecture powered by AsyncAPI specification. It assists in designing specifications, documentation of APIs, boilerplate code generation, community support, and open governance.
Overall, it is easy to say that everything that happens within and to your enterprise such as customer requests, updates to the system of records, IoT sensor readings, inbound/outbound communication are “events”. The true value of the event is gained if a system can intelligently react to it. The more quickly it reacts to events — the business can effectively react to opportunities resulting in higher customer satisfaction, improved operational efficiency, and reduction in resource consumption. Not only that but EDA also helps in building a responsive, scalable, loosely coupled, and agile ecosystem for system integrations.
