Events as Meaningful Facts

Goal

The previous chapter separated services by ownership. Event-driven architecture asks how those services can react to meaningful changes without making the producer call every consumer directly.

The first discipline is vocabulary. An event is not a vague trigger and not a hidden command. It is a fact that something happened.

The durable idea is:

An event records a meaningful fact that other parts of the system may react to.

The Short Version

The simple description is:

One system publishes an event, and other systems react.

That is true, but it is thin. A stronger architecture description is:

One system publishes a well-defined fact, a routing layer delivers it to interested consumers, handlers process it safely, durable processing protects important work when needed, and teams can see failures.

The first version sounds like a trigger. The second version sounds like something a team can operate.

Events, Commands, Requests, and Streams

An event says that something already happened.

Examples:

OrderPlaced
PaymentAuthorized
InventoryAdjusted
CustomerProfileChanged
DocumentUploaded

A command asks another component to do work, such as ReserveInventory, GenerateInvoice, or SendShipmentNotification. Commands usually have a clearer receiver and stronger completion expectations.

A request asks for an answer now, usually through an API. A stream carries many records over time, often for telemetry, analytics, or high-volume ingestion.

These distinctions matter because each communication style has different ownership and failure behavior.

Communication	Meaning	Typical Question
Request	Answer this now.	Can the caller continue without the response?
Command	Do this work.	Who owns completion and retry?
Event	This happened.	Who cares and how should they react?
Stream	Here is a sequence of records.	Who consumes the flow and at what volume?

Why Event Meaning Matters

Events can reduce direct coupling. The order service can publish OrderPlaced without knowing every subscriber. Inventory, notifications, analytics, fraud, and fulfillment can each decide whether to react.

But events do not remove all coupling. Coupling moves into the event name, schema, version, payload policy, identifiers, delivery behavior, and operational expectations. A vague event such as DataChanged forces every subscriber to guess what happened. A huge event payload can expose producer internals. A renamed field can break subscribers even though no API endpoint changed.

Good event design starts with business meaning:

Business change
  -> Event fact
  -> Event contract
  -> Subscribers decide whether to react

Example: Order Placement

In a commerce platform, PlaceOrder and OrderPlaced are not interchangeable.

PlaceOrder is a command. It asks the order capability to attempt work. It may fail validation, reject payment, or create an order.

OrderPlaced is an event. It announces that an order now exists. Inventory may reserve stock. Notifications may email the customer. Analytics may update projections. Fulfillment may start later if the order reaches the right state.

The order service owns the fact and its contract. Subscribers own their reactions.

Checkout sends command: PlaceOrder
Orders service records order
Orders service publishes event: OrderPlaced
  -> Inventory reacts
  -> Notification reacts
  -> Analytics reacts

This keeps the producer from hardcoding every downstream reaction. It also requires contract discipline so subscribers know what OrderPlaced means.

Common Mistakes

Naming events like commands, such as ProcessOrderNow.
Publishing vague events such as DataChanged or ThingUpdated.
Treating events as free of contracts.
Including too much private internal state in an event.
Assuming event-driven architecture automatically removes coupling.
Using events for work that actually needs a clear receiver and durable completion.

If Someone Asks You

What is an event in architecture terms?

A good answer is:

An event is a named fact that something meaningful happened. It lets interested consumers react without making the producer call each one directly. A good event still needs an owner, schema, versioning rules, identifiers, correlation, and operational visibility. If the message is asking for work rather than announcing a fact, I treat it as a command instead.

What You Should Remember

Events are facts with owners and contracts.

Questions to Check Understanding

How is an event different from a command?
Why should event names be meaningful?
What coupling remains in event-driven systems?