Observer vs pub/sub

Published 21 October 2026

Both patterns solve the same problem. Something happens (an order is delivered) and several other parts of the system need to react, but the part where it happened should not have to know who they are. The difference is one thing: is there a middleman?

Think of a school. Observer is the class teacher making an announcement in the room. The teacher has the attendance register (the list of listeners), says it once, and everyone in the room hears it straight away. Anyone who is absent today never hears it. Pub/sub is the parents' WhatsApp group. The school posts once to the group and has no idea who is in it. A phone that is switched off gets the message when it comes back on, and the school did not wait for anyone to read it.

One event, two wirings#

These are the same five reactions from the opening of the observer chapter. Switch the wiring, then turn on a problem or two.

Observer: the subject calls its listeners#

The subject keeps the listeners in memory and calls each one, in order, inside notify. This is the version from the LLD course, which catches errors per listener so one bad listener cannot stop the rest:

type Listener<T> = (event: T) => void
 
class Subject<T> {
  private listeners = new Set<Listener<T>>()
  subscribe(fn: Listener<T>) {
    this.listeners.add(fn)
    return () => this.listeners.delete(fn)
  }
  notify(event: T) {
    for (const fn of this.listeners) {
      try {
        fn(event)
      } catch (e) {
        console.log(`listener failed: ${(e as Error).message}`)
      }
    }
  }
}
 
const delivered = new Subject<{ orderId: string }>()
delivered.subscribe((e) => console.log(`points for ${e.orderId}`))
const stop = delivered.subscribe(() => {
  throw new Error('analytics down')
})
delivered.subscribe((e) => console.log(`pay rider for ${e.orderId}`))
 
delivered.notify({ orderId: 'A17' })
// > points for A17
// > listener failed: analytics down
// > pay rider for A17
console.log('markDelivered done') // markDelivered done
 
stop()
delivered.notify({ orderId: 'A18' })
// > points for A18
// > pay rider for A18

Look at where markDelivered done is printed: after every listener. Everything ran inside notify, one after another, before the caller got control back. That is what makes observer simple and fast when the listeners are small. It is also why a slow listener makes the caller slow, and why the failed analytics call is gone for good: nothing kept the event to try again.

Node's EventEmitter and the browser's addEventListener are observer. Node's documentation says it plainly: emit calls the listeners synchronously, in the order they were added.

Pub/sub: a broker in the middle#

In pub/sub the publisher hands a message to a broker under a topic name, and returns. Subscribers ask the broker for messages on that topic. The publisher does not hold a list of subscribers, does not call them, and does not wait for them.

Here is a toy broker in a few lines. It keeps one queue per subscriber, which is enough to show the two properties that matter:

class Broker {
  private topics = new Map<string, string[]>() // topic to subscribers
  private queues = new Map<string, string[]>() // one per subscriber
 
  subscribe(topic: string, name: string) {
    this.topics.set(topic, [...(this.topics.get(topic) ?? []), name])
    this.queues.set(name, [])
  }
  publish(topic: string, message: string) {
    for (const name of this.topics.get(topic) ?? []) {
      this.queues.get(name)?.push(message)
    }
  }
  poll(name: string) {
    const waiting = this.queues.get(name) ?? []
    this.queues.set(name, [])
    return waiting
  }
}
 
const broker = new Broker()
broker.subscribe('order.delivered', 'earnings')
broker.subscribe('order.delivered', 'invoice')
 
// The order service knows a topic name, not who is listening.
broker.publish('order.delivered', 'A17')
broker.publish('order.delivered', 'A18')
 
console.log(broker.poll('earnings')) // [ 'A17', 'A18' ]
// The invoice service was down for both. Its messages waited.
console.log(broker.poll('invoice')) // [ 'A17', 'A18' ]

publish did not run any subscriber code, so it takes the same time with one subscriber or fifty. And a subscriber that was away gets what it missed. Real brokers (Kafka, RabbitMQ, SNS feeding SQS queues) do the same thing across machines, with disks, acknowledgements and retries, which is the subject of queue vs pub/sub vs event stream.

What the middleman changes#

The last row matters in a design discussion. With pub/sub, publish returning tells you the broker has the message, not that the invoice was sent. If checkout must not finish until something has happened (the payment is captured), that call should be a direct call, not an event.

In the interview#

Checkpoint#