# Push vs Pull

> Push lets a sender deliver updates when they are available; pull lets a receiver request updates when it is ready. Choose push for timely delivery to interested receivers, and pull for receiver-controlled pacing or data needed only on demand. Many systems combine push notifications with pull-based retrieval and recovery.

Source: https://sysround.com/compare/push-vs-pull
Updated: 2026-11-05


## Side by side

| | Push | Pull |
|---|---|---|
| Delivery trigger | Push: sender delivers after an event | Pull: receiver requests data |
| Freshness | No periodic polling delay | Depends on polling interval; long polling reduces delay |
| Idle overhead | Connections, heartbeats, or callback registration | Periodic polls can return no changes |
| Pacing | Needs explicit flow control | Receiver controls fetch rate and batch size |
| Scaling pressure | Connections, routing, and event fan-out | Read traffic and synchronized polling |
| Slow receivers | Bound buffers; pause, drop, or disconnect | Lag grows in retained data |
| Recovery | Requires replay, retries, or snapshot retrieval | Can resume from a durable cursor |
| Typical interfaces | Webhooks, SSE, WebSocket updates | Polling APIs, long polling, consumer fetches |

## The differences that matter

Define the boundary before comparing. A browser can initiate an SSE connection, but subsequent updates are server-pushed. Long polling is pull because each response fulfills a receiver request, even though the server waits for data. Feed fan-out on write versus read is a related but separate choice: precomputing a feed does not require pushing it to the client.

Push removes the wait for the next periodic poll, but does not eliminate queueing or network delay. Periodic pull trades freshness for request volume: shorter intervals improve freshness while increasing reads, including empty reads. Long polling avoids many empty responses but still requires held connections and timeout handling.

Pull makes receiver pacing straightforward: fetch another batch only when processing capacity is available. Push needs explicit limits such as credits, maximum in-flight messages, or bounded per-client buffers. Neither model removes overload; a slow consumer eventually runs into buffer, retention, or storage limits.

Push delivery to many subscribers shifts cost toward connection management, subscription routing, and fan-out. Pull shifts cost toward read endpoints and repeated queries, which may benefit from shared caches. For a hot audience, coalescing updates or distributing a shared snapshot can matter more than which side initiates delivery.

Neither model guarantees durability, ordering, or exactly-once processing. Reliable delivery needs explicit retention, acknowledgments or offsets, retries, and duplicate handling. A common hybrid pushes a change notification, then lets the receiver pull authoritative data using a version or cursor.

## Choose Push when

- Clients need timely chat messages, live comments, or price changes without repeatedly checking for updates.
- Updates are sparse relative to how frequently clients would otherwise poll, and connection or callback overhead is acceptable.
- Subscribers are known and reachable through persistent connections or registered webhook endpoints.
- You can define bounded buffering, slow-consumer handling, and a recovery path for disconnected receivers.

## Choose Pull when

- Workers have different processing speeds and should fetch work only when they have spare capacity.
- Consumers need independent offsets, batching, and replay over a retained event log.
- Data is useful only when a user requests it, so proactively delivering every change would waste work.
- A modest freshness delay is acceptable, and periodic requests are simpler to operate than persistent delivery connections.

## Worked example: Live order-status updates

Suppose 100,000 customers have an order-tracking page open, and the freshness target is two seconds. Polling every two seconds creates about 50,000 requests per second, even if few orders change. Under uniformly timed changes, polling adds about one second of average detection delay, before network and processing time. SSE can deliver changes as they occur, but requires 100,000 open connections plus routing and heartbeat capacity. Choose SSE for the live view, with bounded per-client buffers. On reconnect, the client supplies its last event cursor; if replay is unavailable, it fetches the current order snapshot. Keep a slower polling fallback for environments where streaming fails.

## In the interview

- State the boundary: server to browser, broker to worker, or feed storage to read API. A single system can use different models at each boundary.
- Quantify the freshness target and polling cost. With N active clients polling every T seconds, the baseline request rate is approximately N/T, before retries.
- Explain overload behavior. Expect questions about maximum in-flight work, per-client buffers, queue lag, retention, and whether stale updates may be coalesced.
- Walk through a disconnect. Specify the cursor or version, replay window, duplicate handling, and snapshot fallback when retained history is unavailable.
- Separate the delivery choice from consistency and durability. Expect follow-ups about acknowledgments, ordering scope, authorization changes, and recovery after a server crash.

## Common mistakes

- Calling push inherently reliable or exactly-once. Delivery direction does not define acknowledgment, persistence, or retry semantics.
- Assuming pull always has high latency. Long polling can return promptly when data arrives, while poorly provisioned push systems can queue updates.
- Ignoring idle and overload costs: empty polls on the pull side, and heartbeats, fan-out, or unbounded buffers on the push side.
- Treating fan-out on write versus read as identical to push versus pull delivery. Feed materialization and client delivery are separate design decisions.

## Interview questions where it comes up

- [Design a chat app like WhatsApp](https://sysround.com/questions/design-whatsapp): Push live messages over persistent connections while retaining messages for offline retrieval and reconnect recovery.
- [Design a news feed like Facebook](https://sysround.com/questions/design-news-feed): Distinguish feed materialization on write or read from the separate choice of pushing updates or fetching the feed.
- [Design a distributed message queue like RabbitMQ](https://sysround.com/questions/design-message-queue): Compare broker-initiated delivery with worker fetches while specifying in-flight limits, leases, and acknowledgments.
- [Design a metrics monitoring system like Datadog](https://sysround.com/questions/design-metrics-monitoring-system): Choose push ingestion or pull-based scraping while accounting for target discovery, collection intervals, and missing-data detection.
- [Design a real-time stock price feed](https://sysround.com/questions/design-stock-price-feed): Push timely price updates while bounding slow-client buffers and providing snapshot-based recovery.
- [Design a notification system](https://sysround.com/questions/design-notification-system): Separate worker consumption from outbound push delivery and define retries, receiver limits, and duplicate handling at each boundary.

## FAQ

### What is the difference between push and pull architecture?

In push architecture, a sender initiates update delivery when data becomes available. In pull architecture, a receiver requests data when it wants more. The distinction applies to a particular interface, not necessarily the entire system.

### Is push better than polling for real-time updates?

Push usually fits tight freshness requirements because it avoids waiting for the next periodic poll. It also introduces connection or callback management and slow-receiver handling. Long polling is a useful alternative when prompt updates are needed through a request-response interface.

### Can a system use both push and pull?

Yes. A service can push a lightweight change notification and let clients pull the latest data. It can also push live updates while using cursor-based pull requests for reconnect recovery, provided the handoff avoids gaps.

## Related concepts

- [WebSockets, SSE and long polling](https://sysround.com/concepts/real-time-updates)
- [Backpressure](https://sysround.com/concepts/backpressure)
- [Message queues](https://sysround.com/concepts/message-queues)
- [Webhooks](https://sysround.com/concepts/webhooks)
- [Fan-out on write and on read](https://sysround.com/concepts/fan-out)


---
SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.