An event-driven architecture is based on the idea of message passing as the primary (if not only) means of communication between services and systems. Last time I talked about the anatomy of an event message in an event-driven architecture, and today I want to (briefly) go over the other types of messages in an event-driven system.

Events are temporal verbs: They convey what has happened or is happening.
Commands are imperative verbs: Do this thing. Start this Process.
Queries are requests for information. "What are the orders for customer ID 123?"
Replies follow Queries: They give the answer to the query. "Customer 123 is a cheapskate. They haven't ordered anything."

A few tips:

  • You can make Queries and replies part of your internal system communication mechanism that happens over the message bus. I generally don't recommend this -- as you're essentially reproducing HTTP semantics over AMQP, and that's not necessarily a business you want to be in, but it's up to your context. Both RabbitMQ and Kafka support this set of semantics.
  • If the resilience of a message bus is not required for your use-case, then I'd suggest using synchronous HTTP requests against your HTTP/REST APIs for queries and replies instead of trying to make everything fit around your message bus.