In the Observer pattern, what is the difference between push and pull notification, and what are the trade-offs of each?

## The two shapes When the subject calls its observers, it must decide **how much information travels with the call**. **Push model** — the subject sends the data: ``` interface Observer { update(PriceChanged e) } // e carries symbol, oldPrice, newPrice, timestamp notify(): for o in observers: o.update(PriceChanged(sym, old, new, now)) ``` **Pull model** — the subject sends only a signal: ``` interface Observer { update(Subject s) } // or update() with no arguments at all notify(): for o in observers: o.update(this) // observer body: price = s.getPrice(); if (price != lastSeen) redraw() ``` The original Gang of Four description presents both and calls them the *push model* and the *pull model*; the pull model was described as the more "minimal" subject interface, and the push model as the one that assumes the subject knows observers' needs. ## Push in detail **Advantages** - *Self-contained notification.* The observer receives everything it needs, so it does not need a reference to the subject at all. That is a strictly weaker coupling: the observer depends on an event type, not on a live object with a query API. - *Serializable / relocatable.* Because the event is a value, it can be queued, logged, replayed, put on a message bus, or sent to another process. Pull cannot cross a process boundary — there is nothing to call back into. - *No re-read races.* The payload is a consistent snapshot of the change as of the moment of notification. Even if the subject changes again immediately, the observer still sees the state the event described. - *Efficient for the common case* where every observer wants the same one thing. **Disadvantages** - *The subject must guess.* Designing the event means predicting observer needs. Guess small and observers cast the subject back / call getters anyway; guess big and you compute or serialize data no observer uses (expensive when the payload is a large collection or an eager computed value). - *Event-type churn.* A new observer need often means changing the event class, which means touching the subject — the very coupling Observer set out to remove, now migrated into the payload schema. - *Mutable payload hazard.* Pushing a live reference to an internal collection lets an observer mutate the subject's state, or lets observer #1's edits be visible to observer #2. Push payloads should be immutable, or defensively copied. - *Ordering vs. freshness.* With multiple queued pushes, an observer that processes slowly can be handling event #1 while the world is already at #5 — fine for auditing/replay, wrong for "draw the current value". ## Pull in detail **Advantages** - *Minimal subject-side notification interface* — one `update()` covers every kind of change. - *Observer autonomy.* Each observer reads exactly the fields it cares about; adding an observer with different needs requires no change to the subject or to any event type. - *Naturally coalescing.* If ten changes fired and the observer only reads current state, it converges to the latest value; extra notifications are idempotent redraws. **Disadvantages** - *Coupling to the subject's query API.* Every observer now compiles against getters, so the subject's read surface becomes a public contract that is hard to evolve. Observers may also reach for state that is none of their business. - *Cost.* N observers × M getters, and each getter may recompute. Observers must also figure out *what* changed, often by diffing against a cached copy — logic duplicated in every observer. - *Stale-vs-fresh inconsistency (the "glitch").* Between the notification and the pull, another thread — or a reentrant observer earlier in the loop — may have changed the state. Observer A (called first) may see value v1 and observer B (called later) v2 for what was announced as one event, so views disagree. With push both see the same payload. - *Requires a live reference*, which is exactly the reference that keeps a dead observer's subject-graph reachable and complicates lifetime management. ## The hybrid, which is what real APIs actually do Almost every mature listener API pushes a *small change descriptor* and lets the observer pull details: - Property-change events: `(propertyName, oldValue, newValue, source)` — enough to filter cheaply, plus a `source` handle to pull more. - Collection change events: `(kind = insert/remove/replace, index, count)` — the observer pulls the items only if it is going to render them. - Database/CDC change feeds: `(table, primary key, operation)` and the consumer fetches the row if it needs it. This is the answer most interviewers are looking for: *push what is cheap and identifying, let the observer pull what is expensive or observer-specific.* ## Choosing Prefer **push** when: notification may become asynchronous or cross-process; observers are simple and mostly want the same value; you need each observer to see an identical, consistent snapshot; you want an audit/replay log for free. Prefer **pull** when: observers have widely different, unpredictable needs; the state is large and rarely fully consumed; "latest value wins" semantics are correct and coalescing is desirable; the subject's query API is already public and stable. And in both models: **do not notify when nothing changed** (equality-check first), and **document whether the payload is a snapshot or a live view**.