Not All Commands Are Equal (And Neither Are Events)

Usually, in an event-driven architecture, events are emitted by one service and listened to by many (1:n). But what if it’s the other way around? If one service needs to listen to events from many other services?

When we talk about communication between services, we distinguish between commands, queries and events. For events and queries, let’s say we agree on these attributes:

I don’t expect controversy here. For a query, you want a response. And on the other hand it’s well established that events describe facts. And that events are emitted, with no knowledge required what’s listening to the event and reacting to it. And certainly no response is expected.

Let’s agree that a command expresses intent, it’s a request to do something. An example could be a request to cancel an order (trigger e.g. by a request from a user). This can fail, in multiple ways: The referenced order might not exist, it might be already fulfilled and no longer cancelable, or the user might not be authorized to cancel it. That’s why a command typically yields a response: An acknowledgment that is has been executed successfully, or an error message. Consequently, the communication pattern is request-response. The caller will need the response to decide on the next action.

This is the kind of command I usually mean when I talk about commands (which I do a lot, even publicly). But while doing so, I learned that a lot of people disagree with the association command = request - response. So let’s differentiate, and call commands that expect a response “ask commands”.

Leave a Comment