Events vs Commands

The Distinction

 COMMAND: an INSTRUCTION — "do this" — directed at ONE receiver.
   CancelOrder(order-42)
   → order service MUST handle it; it's addressed to them.

 EVENT: a FACT — "this happened" — broadcast to anyone listening.
   OrderCancelled(order-42, reason, at)
   → past tense; producer doesn't know or care who reacts.

 [checkout] ──CancelOrder──► [orders]        command: 1 target,
                             must obey/refuse    imperative

 [orders] ──OrderCancelled──► {email, analytics, inventory}
                              events: N observers, informative

Why the Confusion Is Expensive

 teams blur them and build subtle wrongness:

 treating commands as events:
   publish RefundRequested hoping SOMEONE processes it
   → no owner → dropped refunds. commands need GUARANTEED
   delivery to a RESPONSIBLE handler.

 treating events as commands:
   OrderPlaced consumed by inventory which then MUTATES stock...
   fine! but now inventory's behavior is coupled to checkout's
   event FORMAT — rename a field, break a stranger.

 the naming test:
   past tense verb = event (OrderShipped ✓)
   imperative verb = command (ShipOrder ✓)

The Flow of a Proper Design

 commands enter, events radiate:

 user ──PlaceOrder──► [order svc]     ← command boundary
                          │ decides, persists, emits
                          ▼
                    OrderPlaced ──► {inventory, email, analytics}
                          
 inventory REACTS to the fact (reserves stock), 
 emits StockReserved ──► ... chain continues as facts.

 rule of thumb: COMMANDS at system edges (user intent, service
 requests); EVENTS inside/between domains (facts propagating).

Practical Consequences

Property	Command	Event
Delivery	must-reach-handler (retries/DLQ critical)	interested-parties subscribe
Failure	handler rejects → caller informed	consumers fail independently
Coupling	producer↔handler contract tight	loose; additive evolution
Validation	handler validates + responds	none possible post-facto

 error handling differs radically:
 rejected command → tell the SENDER (synchronous-ish path)
 failed event consumption → consumer's own retry/DLQ;
 sender neither knows nor cares.

Interview Framing

Design reviews score this vocabulary silently: candidates who label arrows correctly (command into the domain, events out) draw architectures whose failure semantics actually work. Use the words precisely — “the checkout issues PlaceOrder; orders emits OrderPlaced” — and the interviewer stops worrying about your fundamentals. One sentence to keep: “commands are requests, events are receipts.”