Skip to main content

Push vs Pull Architecture

Webhooks and CDN both pointed to this lesson as the general pattern behind a specific choice they each make: does the side with new data send it out (push), or does the side that wants data go ask for it (pull)? Nearly every data-movement decision in this course is an instance of one of these two.

Pull: the receiver asks​

Pull is the default, and it's the shape Client-Server Architecture assumes throughout this entire course: a client wants something, so it asks for it. Polling — repeatedly asking "anything new?" — is pull taken to its simplest extreme, and its cost is exactly proportional to how often you ask relative to how often the answer actually changes: poll too rarely and updates are stale; poll too often and most requests return "nothing changed," wasted work on both sides.

Push: the sender initiates​

Push flips this: the side with new data sends it, without waiting to be asked. Webhooks are push implemented as a single HTTP callback; Pub/Sub is push implemented as a broker-mediated fan-out to many subscribers at once. Both remove the core inefficiency of polling entirely — the receiver finds out the instant something happens, with zero wasted "anything new?" requests in between.

System Design Lab

Why pull isn't just "the worse option nobody should use"​

Push looks strictly better at first glance — no wasted requests, instant delivery — but it has a real, structural requirement pull doesn't: the sender needs to know who to push to, and that receiver needs to be reachable right now. Pull inverts this cleanly: the receiver controls entirely when it asks, doesn't need to expose anything reachable to the sender, and can catch up on its own schedule (even after being offline) simply by asking once it's ready — no missed-delivery problem to solve at all, because nothing was ever "sent" while the receiver wasn't listening.

Where each one actually shows up in this course​

Naming the concrete instances makes the abstract pattern concrete: a CDN pulling content from an origin the first time it's requested is pull (the standard, simpler default); a CDN pre-populating edge locations ahead of a scheduled release is push, chosen specifically because content needs to be guaranteed present before the first request rather than fetched lazily. A Webhook is push because the receiver's URL is known upfront and reachable; a client polling an endpoint for job status is pull, often chosen specifically because the client doesn't want to expose a reachable endpoint of its own just to receive one callback.

The reachability requirement is the real decision driver​

This is the detail worth stating explicitly rather than treating push as strictly superior: push requires the sender to reliably know the receiver's current address and requires the receiver to be reachable and available at push time (with retry logic to handle when it isn't) — real infrastructure that pull entirely avoids by construction. A receiver behind a firewall, on an unreliable connection, or that simply doesn't want to run a publicly reachable endpoint is a receiver pull was built for.

Why this matters in an interview​

The choice comes down to one question worth asking explicitly: does the receiver need to be reachable and known in advance, and is that an acceptable requirement for this specific design? If yes, push removes real inefficiency. If the receiver's availability or reachability can't be guaranteed, pull's "ask when ready" model sidesteps the problem push would otherwise have to solve with retries and delivery guarantees.

Push vs. pull: pros and cons​

Pros

  • No wasted "anything new?" requests — the receiver finds out the instant something happens
  • Removes the latency of a polling interval entirely
  • Scales naturally to fan-out — one event reaching many receivers at once, as with pub/sub

Cons

  • Requires knowing the receiver's current, reachable address in advance
  • Needs retry/delivery-guarantee logic for when the receiver isn't currently reachable
  • Doesn't work at all for a receiver that can't or won't expose a reachable endpoint

Further Reading​

Saved locally in your browser — visible in the sidebar as you go.