An e-commerce platform integrates order, inventory, payment, logistics and notification through events. Which events should be commands and which should be notifications, and why does confusing them cause outages?

The distinction

A notification states a fact: "order 123 was placed". The publisher does not care who listens or what they do. Adding a consumer requires no change to the publisher, and a consumer failing does not affect the publisher.

A command requests an action: "reserve inventory for order 123". There is an expected effect, someone is responsible for it, and the sender needs to know whether it happened.

They frequently look identical on the wire, which is exactly why they get confused.

Why confusing them causes outages

Treating a command as a notification produces work that silently does not happen. "Order placed" is published; inventory happens to listen and reserve. Now inventory reservation is an implicit side effect of a notification with no owner, no acknowledgement, no timeout and no retry policy. If the inventory consumer is down, orders are accepted and nothing is reserved — and nobody finds out until fulfilment.

Treating a notification as a command produces coupling and cascading failure. The order service waits for confirmation from analytics, search indexing and the recommendation system before completing. Now the availability of order placement is the product of the availability of every optional consumer, and a slow analytics pipeline blocks revenue.

The classification for this flow

Commands (with obligations): - Reserve inventory — must happen, must be confirmed, must be compensated if the order fails. - Charge payment — same. - Request fulfilment — same.

These need an orchestrator: a durable workflow owning the state machine, issuing commands, awaiting replies, enforcing timeouts, and able to answer "why is this order stuck?" Choreographing them means no component knows the order's state, timeouts have no owner, and concurrent cancellation races progression with no arbiter.

Notifications (no obligation on the publisher): - Order placed → analytics, search indexing, recommendations, marketing. - Order shipped → customer email, tracking updates.

These are fire-and-forget. Consumers can be added without touching the publisher, and a consumer being down delays its own work only.

The rule of thumb

Choreograph notifications; orchestrate obligations.

And a design tell: if the publisher would want to know that a consumer failed, it is a command wearing a notification's clothes, and it needs an owner, an acknowledgement and a timeout.

The flash-sale complication

At extreme scale the classification gains a second dimension: which commands must be synchronous. Inventory reservation must be strongly consistent and immediate, because overselling cannot be compensated. Everything else — payment, order creation, fulfilment — can be asynchronous with compensation.

That asymmetry is the real design insight. Find the one invariant that cannot be compensated, protect it synchronously, and let everything around it be eventual.