Event Sources, Routing, and Subscriptions

Goal

The previous section framed an event as a fact. This section explains how those facts move from producers to interested consumers without making the producer own every reaction.

The durable idea is:

Event routing connects facts to interested subscribers without making the source know every reaction.

The Short Version

An event-driven flow has several responsibilities:

Event source
  -> Event contract
  -> Router or broker
  -> Subscription filters
  -> Subscribers and handlers

The source owns the fact. The router owns delivery boundaries. Subscriptions express interest. Subscribers own reactions.

That separation is the point. If the source has to call every subscriber directly, the system may still work, but the producer is now coupled to every downstream reaction.

Event Sources

An event source is the system that knows something happened.

Sources can be application capabilities, platform services, partner systems, SaaS systems, devices, files, databases, or workflow steps. A source should publish a meaningful event name and a stable payload. It should not publish every internal implementation detail.

A good event source answers:

• What fact happened?

• When did it happen?

• Which business object or resource does it describe?

• Which version of the event contract is this?

• Which producer owns the event?

• Which correlation ID connects this event to a larger flow?

The source does not need to know every subscriber. That is routing's job.

Routing, Subscriptions, and Filters

Routing is the responsibility that connects events to interested consumers. A router or broker can fan out one event to several subscribers, apply filters, enforce access rules, and deliver the event through supported protocols.

Filters are useful because not every subscriber should receive every event. A fraud handler may care about high-value orders. An analytics projection may care about all orders. A notification handler may care only about orders that require customer contact.

Filtering should reduce noise, not hide business meaning. If every subscriber needs complex filtering logic to figure out what happened, the event design may be too vague.

Example: Order Event Fan-Out

An order service publishes OrderPlaced.

Orders service publishes OrderPlaced
  -> Event router
      |-- Inventory reservation subscriber
      |-- Customer notification subscriber
      |-- Fraud signal subscriber
      |-- Analytics projection subscriber

The order service owns the event meaning and schema. It does not own inventory's reaction, notification content, fraud analysis, or analytics projection. Each subscriber owns its own validation, idempotency, dependencies, failures, and telemetry.

That is the architectural benefit. The source can remain focused on orders while new reactions can be added through subscriptions and handlers.

Routing Is Not the Same as Work Completion

Routing can deliver a notification that something happened. It does not automatically guarantee that every downstream business outcome completes correctly.

When a reaction becomes work that must complete, add a durable work boundary:

Event router delivers notification
  -> Handler validates event
  -> Durable queue stores work
  -> Worker processes with retry and dead-letter handling

This distinction keeps event routing from becoming an overloaded answer to every asynchronous problem.

Common Mistakes

• Making the source know every subscriber.

• Treating routing configuration as ownerless infrastructure.

• Filtering events so aggressively that important meaning disappears.

• Ignoring permissions and delivery behavior.

• Assuming delivery to a handler means business work completed.

If Someone Asks You

What does event routing own?

A good answer is:

Event routing owns the delivery boundary between event sources and subscribers. The source owns the fact and contract. Subscriptions express which consumers want which events. Handlers own their reactions. Routing helps avoid direct producer-to-consumer coupling, but durable business work still needs retry, idempotency, dead-letter handling, and ownership.

What You Should Remember

Sources own facts; subscribers own reactions; routing owns delivery boundaries.

Questions to Check Understanding

1. Why should sources not know every subscriber?

2. What does a subscription express?

3. What operational concerns appear in routing?