Events vs commands
“What is the difference between an event and a command, and why does it matter which one you send between services?”
What this tests
- Semantics: a fact that happened vs a request to do something
- Who owns the decision and who owns the consequence
- Coupling direction: events decouple the producer from consumers; commands do not
- Naming and payload discipline
Answers by level
Read the beginner answer first and notice what is missing.
A command is a request addressed to one handler: ChargeCard, imperative, may be rejected, and the sender usually cares about the outcome. An event is a fact published by its owner: OrderPlaced, past tense, cannot be rejected because it already happened, and the publisher does not know or care who consumes it. The distinction is about who decides. With a command the sender has decided what should happen; with an event the consumer decides what to do about the fact.
That decides coupling. If the Order service sends SendConfirmationEmail, it knows about email, and adding SMS means changing the Order service. If it publishes OrderPlaced, the Email, Inventory and Analytics services subscribe independently and the Order service never changes when a consumer is added. Commands still have their place: when exactly one party must act and the sender needs to know it did, such as a saga orchestrator telling Payment to charge.
Payload discipline follows: an event carries what happened with enough data for consumers to act without calling back; a command carries the parameters of the request and an identifier so the handler can deduplicate.
Green flags · Red flags
- Command: addressed, imperative, can be rejected. Event: fact, past tense, cannot be rejected
- Explains coupling: events let consumers be added without changing the producer
- Names a legitimate command use (saga orchestration)
- Mentions that events must be published only after the state is durable
- Spots command-in-disguise event names
- "It is just naming; events and commands are the same message with a different tense."
- Publishes events from the producer before committing the state
- Has the Order service send channel-specific commands to every downstream
- Does not know whether the sender needs the outcome
Follow-up questions
OrderPlaced contain?Scenario
SendEmail, UpdateInventory and RecordAnalytics messages after each order, and every new downstream team files a ticket against the Order team. Redesign the messaging so the Order team stops being a bottleneck, and state what changes about payloads and failure handling.