Events vs commands

Events state facts that already happened: OrderPlaced, PaymentCaptured. Commands request work: ReserveInventory, ChargeCard. Mixing them blurs ownership — events are published by the aggregate that changed; commands target a specific handler with intent to mutate.

Events enable many subscribers; commands imply one responsible consumer and clearer retry semantics when tied to idempotency keys.

On interviews: classify messages in a checkout flow; explain why PaymentFailed as a command to email service is wrong modeling.

Common pitfalls: event names in past tense that trigger side effects elsewhere without idempotency; commands broadcast to many consumers; choreography without clear writers.

The trade-off is flexibility versus complexity—know when the simpler path is enough.

Checklist:

• Name events as immutable facts with schema version.
• Route commands to a single owning service.
• Document who may emit and who may react.
• Handle duplicates differently for events vs commands.