Pub/Sub and Fan-Out Patterns

Publish/subscribe in serverless systems is the pattern for one meaningful fact reaching several independent reactions. A topic, event bus, or broadcast channel receives an event, and multiple consumers can react in their own way without the producer calling each one directly. This is one of the most powerful ways to keep systems extensible, because new consumers can often be added without changing the original producer.

The key word is fact. Pub/sub is healthiest when the producer emits a business or technical event that is worth sharing broadly. If the producer is really trying to instruct one downstream worker to do a specific job, a queue is usually the better shape.

    flowchart TD
	    A["Producer emits event"] --> B["Topic or event bus"]
	    B --> C["Consumer: notifications"]
	    B --> D["Consumer: analytics"]
	    B --> E["Consumer: workflow reaction"]
	    B --> F["Consumer: audit trail"]

What to notice:

• the producer publishes once
• each consumer can evolve independently
• this pattern increases extensibility, but only if event meaning remains stable

Why Fan-Out Matters

Pub/sub lets one change drive several downstream actions without building them into the producer directly. That is useful when:

• the downstream reactions are independent
• not all consumers must succeed before the producer continues
• the system benefits from adding new reactions over time

This is common for:

• audit or analytics fan-out
• notifications
• reactive workflow steps
• integration events consumed by several teams

The Strongest Benefit: Independent Evolution

A good pub/sub pattern lets consumers evolve at different speeds. The producer does not need to know every downstream implementation detail. That is especially valuable in growing systems, where new consumers appear after the original event source already exists.

The risk is that the event becomes vague or overloaded. Once consumers infer too much from unstable payload details, the producer is coupled again, just more indirectly.

Event Meaning Is the Core Contract

The event must carry a clear fact:

• order.accepted
• document.uploaded
• customer.onboarding.started

Weak examples are vague labels such as:

• updated
• processed
• something-happened

The transport may fan the message out cleanly, but the architecture still fails if the event contract is fuzzy.

A Typical Fan-Out Example

1event:
2  type: order.accepted
3
4subscribers:
5  - send-order-email
6  - update-analytics
7  - schedule-fulfillment
8  - record-audit-log

 1type OrderAccepted = {
 2  type: "order.accepted";
 3  orderId: string;
 4  customerId: string;
 5};
 6
 7export async function sendOrderEmail(event: OrderAccepted) {
 8  await emailService.send({
 9    template: "order-accepted",
10    customerId: event.customerId,
11    orderId: event.orderId,
12  });
13}

This is strong because:

• the event is meaningful
• the consumers are independent
• the producer does not own each downstream behavior directly

The Real Cost of Fan-Out

Fan-out is not free. It increases:

• contract-governance pressure
• observability complexity
• the number of downstream systems affected by one event
• replay risk if consumers produce side effects

That does not make the pattern weak. It just means extensibility and independence come with operational obligations.

Common Mistakes

• using pub/sub for work that should be processed once by one worker
• publishing vague events that force consumers to guess meaning
• assuming a topic makes every downstream behavior reliable automatically
• adding too many casual subscribers until the event becomes a platform-wide hidden dependency

Design Review Question

A team publishes customer.updated to a topic, and several consumers inspect different payload fields to infer whether they should send email, rescore fraud risk, or trigger billing workflows. Is this strong pub/sub design?

Usually no. The stronger answer is that the event is too vague. Consumers are depending on internal payload interpretation rather than reacting to a clear fact. A healthier pattern would publish more specific events or expose clearer event semantics so fan-out remains extensible without becoming ambiguous.

Check Your Understanding