Observer pattern

In one minute

• Observer lets one object (the subject) tell any number of other objects (observers) that something changed, without knowing who they are. Observers subscribe; the subject keeps a list and calls each one on every change.
• It removes the arrow from the core to its side effects: the stock counter no longer imports the search indexer, the alerting code and the cache. Adding a new reaction is a new subscription, not an edit to the core.
• In-process observers run synchronously on the publisher's thread, in its call stack. That makes them simple and ordered, and it means a slow or failing observer slows or breaks the publisher unless you isolate it.
• The classic bugs are about lifecycle and re-entrancy: observers that are never unsubscribed (the lapsed listener leak), observers that unsubscribe or publish while being notified, and notifications that arrive out of order.
• When observers live in other processes, the same idea becomes pub/sub over a broker, with its own delivery guarantees. Keep in-process Observer for cheap, local reactions.

How it works

The problem

An inventory service keeps a stock count per product. When a count changes, four things must happen: the search index updates the "in stock" flag, a low-stock alert fires below 10 units, a product page cache entry is dropped, and the analytics pipeline records the change. The first version does all of that inside set_stock:

def set_stock(self, sku, qty):
    old = self.stock[sku]
    self.stock[sku] = qty
    self.search.update(sku, qty > 0)
    if qty < 10 <= old:
        self.alerts.low_stock(sku, qty)
    self.cache.drop(f"product:{sku}")
    self.analytics.record("stock", sku, old, qty)

The inventory class now depends on four other teams' code. Each new reaction is a change to the core, and a test of the stock arithmetic needs four fakes. When the analytics client throws, the stock update looks failed even though it succeeded.

Invert the dependency

The subject offers subscribe(callback) and calls every callback when the value changes:

class StockLevel:
    def __init__(self):
        self.observers = []

    def subscribe(self, fn):
        self.observers.append(fn)
        return lambda: self.observers.remove(fn)

    def set(self, sku, old, new):
        for fn in list(self.observers):
            fn(sku, old, new)

Each team registers its own reaction at startup. The inventory code knows only that someone may be listening. This is the dependency inversion principle applied to side effects, and it is how GUI toolkits, DOM events, Node's EventEmitter, reactive stores (MobX, Svelte stores, signals) and the elevator and parking-lot display boards in this course are wired.

Push or pull

A notification can carry the data (push: fn(sku, old, new)) or just say "I changed" and let the observer read what it needs (pull: fn(subject)). Push is simpler and gives each observer a consistent snapshot of that change. Pull lets observers fetch only what they need, but an observer that reads later may see a newer value than the one that triggered it. Most modern APIs push a small event object.

The hard parts are lifecycle and re-entrancy

Three situations break naive implementations.

1. Unsubscribe during notification. An observer removes itself (a one-shot listener) or another observer while the subject is iterating the list. Mutating a list while iterating it skips elements or throws. Iterate over a snapshot, and decide whether a listener removed mid-delivery still gets the current event. The DOM says no (removed listeners are flagged and skipped); Node's EventEmitter says yes (it iterates a copy).
2. Publishing during notification. An observer reacts to 0 -> 1 by setting the value to 2. If the subject notifies recursively, observers later in the list see 1 -> 2 before 0 -> 1. Queue nested changes and deliver them after the current round, so every observer sees changes in the same order.
3. Failing observers. One observer throws. Without isolation the remaining observers are skipped and the exception reaches the code that changed the value. Catch per observer, collect or log the error, and keep going.

The Practice section builds a value cell that handles all three.

Forgetting to unsubscribe

A subject holds a strong reference to every callback, and every callback holds whatever it closes over, often an entire screen or request context. A component that subscribes on creation and never unsubscribes stays in memory forever and keeps reacting to events for a page the user left an hour ago. This is the lapsed listener problem. The fixes are a disposable handle (subscribe returns an unsubscribe function), lifecycle helpers (AbortSignal passed to addEventListener, React's effect cleanup), or weak references (Python's weakref.WeakMethod) when the subject should not keep observers alive.

Reviewing agent-written code

Agents add observers readily and forget teardown, because the subscribe call is in the code they were asked to write and the unsubscribe belongs in a lifecycle method they did not open. In review, look for every subscribe, on or addEventListener and find its matching removal. Also check whether a new observer does slow work (an HTTP call, a database write) synchronously. If it does, it adds that latency to every change, and it belongs behind a queue.

The same shape elsewhere

Observer is the fan-out shape inside one process. The same shape appears in Postgres LISTEN/NOTIFY, Kubernetes informers built on etcd watches, webhook subscriptions, and broker topics. Each one faces the questions this lesson raises at a larger scale: what happens to a slow subscriber, what order events arrive in, and how subscriptions are cleaned up. The event-driven architecture lesson in the system design course covers the cross-process version.

Down the stack

Diagram

sequenceDiagram
  participant C as Caller
  participant S as Cell
  participant A as Observer A
  participant B as Observer B
  C->>S: set(1)
  S->>S: value = 1, queue (0, 1)
  S->>A: notify(0, 1)
  A->>S: set(2) during delivery
  S->>S: value = 2, queue (1, 2), return
  S->>B: notify(0, 1)
  S->>A: notify(1, 2)
  S->>B: notify(1, 2)
  S-->>C: errors from both rounds

Worked example

An online shop changes stock about 800 times per second at peak. The StockLevel subject had five synchronous observers. Four were fast (under 50 us each). The fifth, added for a marketing dashboard, posted every change to an HTTP endpoint with a median of 25 ms and a p99 of 300 ms. Checkout updates stock for every line item, and an average cart has 3 items, so checkout p99 rose by almost a second. During a dashboard outage the HTTP client threw on every call, and because the subject did not isolate failures, the cache-invalidation observer registered after it never ran. Customers saw "in stock" for sold-out items for 20 minutes.

The fix had three parts. The subject now catches each observer's error, logs it with the observer's name, and continues. The dashboard observer only appends to an in-memory buffer (about 1 us), and a background worker ships batches of 500 events every second, dropping the oldest when the buffer passes 50,000 so a dead dashboard cannot exhaust memory. And the cache invalidation moved first in the list with a comment explaining why. Checkout p99 returned to 180 ms, and a later dashboard outage changed nothing customers could see.

Trade-offs

Pitfalls in production

• Lapsed listeners: components subscribe and never unsubscribe, so memory grows and old screens keep reacting. Fix: return an unsubscribe handle and tie it to the component's lifecycle; alert on listener counts.
• Slow observers adding latency to every change. Fix: keep synchronous observers under a microsecond budget and move anything with I/O behind a queue.
• One exception stopping delivery to the rest. Fix: isolate each observer, record the error with the observer's name, and continue.
• Recursive notification when an observer changes the subject, so observers see changes out of order or the stack overflows. Fix: queue nested changes and drain them after the current round.
• Calling observers while holding the subject's lock, causing deadlocks when an observer calls back. Fix: snapshot the list under the lock and notify outside it.
• Depending on observer order without saying so. Fix: if order matters, make it explicit (priorities or a single composed observer), not an accident of import order.

Leadership lens

• Decide per reaction whether it may fail the change. A ledger entry probably must be in the same transaction; a dashboard update must never block checkout. Observer is for the second kind.
• Ask "what happens if the process crashes between the change and the notification?" If the answer is "we lose money or data", the reaction needs an outbox or log, not a callback.
• Track subscription counts per subject as a metric. A count that only grows is a leak you can catch before the out-of-memory kill.
• Give each observer a name and an owner, and log errors with both. Anonymous lambdas in a listener list are hard to debug at 3 a.m.
• When agents add observers, require the teardown in the same change and a note on whether the observer does I/O.

Check yourself

1. An observer reacts to a change from 0 to 1 by setting the value to 2. With naive recursive notification, what does an observer later in the list see, and how do you fix it?

   Show answer

   It sees 1 to 2 before 0 to 1. Queue nested changes and deliver them after the current round so every observer sees the same order.

2. Why does Node's EventEmitter still call a listener that another listener removed during the same emit, while the DOM does not?

   Show answer

   emit iterates a copy of the listener array taken before dispatch. The DOM marks removed listeners with a flag and skips flagged entries during dispatch.

3. Why should a subject never call observers while holding its own lock?

   Show answer

   An observer that calls back into the subject would deadlock, and a slow observer would block every other thread waiting for the lock.

4. When should a reaction move from an in-process observer to a message broker?

   Show answer

   When it lives in another process, is slow, or must not be lost if the process crashes between the change and the notification.

Watch

• Observer Pattern, Design Patterns ep 2 (Christopher Okhravi): push versus pull and the subject and observer interfaces, drawn step by step.
• 10 Design Patterns Explained in 10 Minutes (Fireship): a quick look at observer next to other patterns in JavaScript.

Free resources

• Observer (Game Programming Patterns, Robert Nystrom): an honest discussion of observer costs, including synchronous dispatch and dangling observers.
• Events (Node.js docs): EventEmitter semantics, including listener copies during emit, the 'error' event and the max listeners warning.
• EventTarget.addEventListener (MDN): once, passive and signal options for removing listeners with an AbortController.
• weakref (Python docs): WeakMethod and weak collections for subjects that should not keep observers alive.
• CopyOnWriteArrayList (Java docs): the snapshot-iteration list that suits listener registries.
• Lapsed listener problem (Wikipedia): the leak that comes from forgetting to unsubscribe.