Pub/Sub & Event-driven

The three roles

Where Observer has two participants, pub/sub has three — and the new one, the broker, is the whole point:

• Publisher — produces a message and hands it to the broker on a named topic: publish("orders", msg). That's it. It never holds a subscriber list, never loops over anyone, and gets no answer back about who received it.
• Broker (the event bus) — the middleman. It owns the topic-to-subscriber lists and exposes two doors: subscribe(topic, handler) adds a handler to a topic's list, and publish(topic, msg) looks up that topic's list and delivers a copy to every handler on it. Publishers and subscribers only ever talk to this.
• Subscriber — registers a handler with the broker for the topics it cares about, then reacts whenever a message arrives. It never knows who published, or whether other subscribers exist.

type Handler = (payload: unknown) => void;

class EventBus {                                  // the BROKER
  private topics: Record<string, Handler[]> = {}; // topic -> subscriber list

  subscribe(topic: string, handler: Handler) {    // a subscriber signs up
    (this.topics[topic] ||= []).push(handler);
  }

  publish(topic: string, payload: unknown) {      // a publisher emits
    for (const h of this.topics[topic] || []) {   // route to THIS topic only
      h(payload);                                  // deliver a copy to each
    }
  }
}

Read the two methods carefully: publish never mentions a subscriber, and subscribe never mentions a publisher. They only share a string — the topic name. That string is the entire contract between the two sides.

Topic routing — the message only goes where it's addressed

A message published to "orders" reaches only the handlers that subscribed to "orders". A subscriber tuned to "payments" hears nothing. This is what makes one broker able to carry many independent conversations at once without them bleeding into each other — the topic is the channel.

The decoupling payoff

Because the two sides only share a topic name, you can add, remove, or replace subscribers freely — while the system runs, and even in other processes or machines — without the publisher noticing. This is the headline benefit:

• Add a consumer with zero producer changes — a new analytics service subscribes to "orders"; the order publisher's code is untouched.
• Cross a boundary — the broker can be an in-memory object, or a network service (Redis, Kafka, SNS). Publisher and subscriber can live in different processes, languages, or data centres.
• Fan out for free — one publish naturally reaches many subscribers; going from one consumer to five is a subscription change, not a rewrite.

Observer vs pub/sub — close cousins, not twins

In [[observer]], the subject holds its observer list itself and calls each observer's update() synchronously, in the same process — the two sides are coupled at least through that interface, and the observer knows which subject it joined. Pub/sub adds a broker in the middle: publishers emit to a topic, subscribers register with the broker, and neither side references the other at all — not even by interface. That extra hop is what lets delivery become asynchronous or travel over a network. If your middleman starts making decisions about who should talk to whom (not just fanning out by topic), you're drifting toward a [[mediator]].

The trade-offs of going event-driven

The anonymity that buys you decoupling also takes something away: you can no longer read the flow straight off the code.

• "Who handled this?" — a publisher just drops a message and moves on. Following what actually happens next means knowing every subscriber, which isn't visible at the publish site. Debugging shifts from reading a call stack to tracing events.
• Eventual consistency — subscribers react on their own schedule, so the system is briefly out of sync after each event. You give up the instant, all-in-one-transaction feel of a direct call.
• Delivery guarantees — a networked broker chooses between at-least-once (may deliver duplicates — handlers must be idempotent) and at-most-once (may drop). Exactly-once is famously hard.
• Ordering — messages can arrive out of order, especially across partitions or retries; if order matters you must design for it explicitly.
• The invisible web — it's easy to grow an untraceable tangle where event A fires B fires C, and no one can say what a single publish will ultimately trigger.

Reach for pub/sub when...

• Many consumers must react to the same event, and the set keeps changing — one "order placed" needs to reach email, inventory, and analytics today, and fraud-check tomorrow, without editing the producer.
• Producers and consumers should be independently deployable — decoupling through a broker lets teams ship, scale, and restart their services on their own schedule.
• Work can happen asynchronously — the publisher doesn't need to wait for or hear back from the consumers; fire-and-forget is fine, or even desirable for smoothing load spikes.
• You're building an event-driven system across process or network boundaries — where a shared broker (Kafka, RabbitMQ, SNS/SQS) is the natural backbone.

Skip it when...

• A simple direct call is clearer — if A always calls B and only B, a broker and a topic name are indirection with no payoff. Just call the function.
• You need a guaranteed synchronous result back — pub/sub is fire-and-forget; it returns nothing about who received the message. Use a direct call or request/response instead.
• Strict ordering, tracing, or transactions matter more than decoupling — when you must reason precisely about the sequence of effects or roll them back atomically, the event web's opacity works against you.