Events, Commands & State

The three things a message can be

Every record on a topic is one of these, and mixing them is the root of most event-driven design pain:

Commands have exactly one logical handler and can be rejected. Events are immutable facts with zero-to-many subscribers and can never be rejected (they already happened). State is what you get when you compact a stream of events by key. The single most common beginner mistake is publishing commands dressed up as events (SendEmail on a topic named email.events) — now you have hidden point-to-point coupling masquerading as pub/sub.

A command is a work order taped to one technician's locker — it expects an answer and can be refused. An event is the factory's public bulletin: 'Line 3 finished batch 88'. Anyone may read it, nobody can un-finish the batch. State is the whiteboard showing the current count per line — only the latest number matters.