Member-only story
Commands in an Event-Driven Architecture
When we think of event-driven architecture (EDA), we naturally think of fire-and-forget events. But what happens when we need a response?
We use Event-Driven Architecture as a way to decouple functionality within our software. It can allow the software to be built to be highly fault-tolerant and scalable.
Often, when we first think about EDA, we focus on Events. That’s fair enough, right? I mean, it is called Event-Driven Architecture, after all. The interactions between microservices probably follow the conformist relationship type (from Domain-Driven Design), so an upstream service creates an event, and a downstream service consumes it.
There are numerous ways to implement this event-based relationship, such as using Anti-Corruption Layers. But the premise remains the same: an event is produced, and an event is consumed. The upstream service does not care what the downstream service does with the event or even if the event is consumed at all. Fire-and-forget.
The problem with this pattern is when the upstream service does care what happens to the event.
Example
A microservice (“domain service”) encapsulates some domain logic. Its responsibility is to implement that logic, but it needs to interact with a third party. The interaction is complex due to the third party’s old-fashioned API. So a separate microservice (“gateway service”) is created to encapsulate this complex integration logic. This frees the domain service from concentrating on the problem space, not the integration complexity.
In this example, when the domain service instructs the gateway service to perform a task, it must know that the gateway service has carried out that task.
Different Types of Messages
So we know about Events, but there are other messaging protocols in Event-Driven Architecture. EDA is more about designing for asynchronous processing than strictly using Events as the only communication…
