Request-Response vs Event-Driven APIs
At its core, request–response is a message exchange pattern in which a requestor sends a request message to a replier system. The replier system receives and processes the request, and if all goes well, it returns a message in response. While this exchange format works well for more structured requests, it limits integrations to those where the expectant system has a clear idea what it wants from the other. These request-response style APIs, therefore, must follow the interaction script from the calling service.
In an event-driven architecture, applications integrate multiple services and products as equals based on event-driven interactions. These interactions are driven by event emitters, event consumers, and event channels, whereby the events, themselves, are typically significant ‘changes in state’ that are produced, published, propagated, detected, or consumed. This architectural pattern supports loose coupling amongst software components and services. The advantage is that an event emitter does not need to know the state of the consumer, who the consumer is, or how the event will be processed (if at all). It is a mechanism of pushing data through a persistent stream.
These architectures are appealing because they function well in asynchronous environments. These APIs do not have to wait for realtime communication since they can trigger certain actions on event delivery. This frees resources by reducing (or eliminating) the need to constantly poll endpoints.
Because event-driven systems are more normalized to asynchronous (and often unpredictable) environments, they can become more responsive than traditional API architectures. This is because services can be activated by triggers fired on incoming events, which is useful even when the payload does not come with explicit instructions.
Event Generator – pushes an event to a consumer when the generator detects a relevant state change.
Event Consumers – consumes and acts on the events produced by generators.
Event Channel – a mechanism whereby the information from an event generator is transferred to the event engine.
Event Processing Engine – an event is processed and a subsequent action is taken.
Downstream Event-Driven Activity – the downstream consequences triggered by the event-driven action.