Push vs pull

The decision

In push, the sender sends data to the receiver as soon as the data changes. In pull, the receiver asks the sender for data, again and again. The choice appears in many places: live scores, payment results, news feeds, metrics. It decides how much work is wasted, how fresh the data is, and who must handle a failure.

Choose pull when

• Changes are frequent. If something new is there at almost every ask, no request is wasted.
• A delay of a few seconds or minutes is fine for the user.
• The receiver wants to set the pace. A slow receiver asks only when it is ready.
• The sender cannot reach the receiver. A phone or a server behind a firewall can open a connection out, but often cannot accept one. A push that the sender starts, such as a webhook, then fails.
• You want the simplest system. A pull is an ordinary request and needs no open connection.

Choose push when

• Changes are rare, but the user needs them quickly. Polling would make many empty requests.
• Many receivers watch the same thing, such as a live match.
• Each ask costs money or counts against a limit, such as a paid API call.
• The sender knows who needs the data, such as a payment provider that calls your webhook. A webhook is a web address on your side that the sender calls when an event happens.

The numbers that change the answer

Two numbers matter: the gap between changes, and the interval between asks.

• Useful share of asks = interval / gap, at most 100%.
• Average delay of a pull = interval / 2.

Worked example at Indian scale. A live cricket score. Assumptions: 500,000 people watch, the score changes every 30 seconds, a phone polls every 5 seconds. One server does 1 ms of work per poll on 4 cores at 70% load. One server holds 50,000 open connections.

Push sends 500,000 / 30 = 16,667 messages per second, and each arrives at once. At 1 ms each, the sends need 16,667 / 2,800 = 5.95, so 6 servers of CPU. That is less than the 10 servers needed to hold the connections. If the score changed every 2 seconds, the useful share would be 100% and push would save almost nothing.

Feeds show the same pattern. Assumptions: one server writes 35,000 list entries per second, and one account has 10,000,000 followers. That post needs 10,000,000 / 35,000 = 286 seconds, which is 4.8 minutes, to push one post into every follower list. So a big account can take minutes on one server. Many systems push for ordinary accounts and let readers pull the biggest accounts.

What breaks with each choice

• Pull: most asks are empty (83,333 per second above). Delay is as long as the interval. If all clients use the same timer, they ask at the same moment. Fix: add a random time to each interval.
• Push: a receiver that is down misses the message. A fast sender can flood a slow receiver. Open connections use memory, and a restart makes all clients reconnect together.
• Push fix: the sender retries, the receiver removes duplicates, and a slow catch-up pull repairs anything missed. Stripe says it retries events for up to three days and does not promise their order (see Sources). A catch-up pull handles that.

What it costs

• Pull is cheap to build. Moving from pull to push needs new servers for connections, retry code and a catch-up job. Plan for weeks of work (rough guess).
• Push needs fewer servers here (11 against 37) but more code: reconnects, retries and a catch-up job.
• A hybrid is common. Push a tiny signal that says "something changed", and let the receiver pull the details.

How each level answers

SDE-1: In push, the sender sends when data changes. In pull, the receiver keeps asking.

SDE-2: For a live score I pick push, because changes are rare and users want them quickly. For a nightly report I pick pull, because delay does not matter and it is simpler.

Senior: With 500,000 viewers and a change every 30 seconds, polling every 5 seconds makes 100,000 requests per second and 83% are empty. Push needs about 11 servers instead of 37. The risk is a mass reconnect after a restart, so clients wait a random time. The fallback is a slow poll that fixes missed messages.

Staff: I ask what a late score costs the business, and who runs the connection servers. I start with polling, because it is easy to undo. I move to push when empty requests or delay cost more than the new servers. I check the choice by the share of empty requests, the delay at the 99th percentile, and the number of missed-message repairs.

Say it in the interview

For a live score I would push over an open connection. The score changes every 30 seconds, so polling every 5 seconds wastes 83% of 100,000 requests per second. The risk is missed messages and mass reconnects, so clients wait a random time and fall back to a slow poll.

Common mistakes

• Saying "push is always better". When changes come faster than the asks, pull wastes nothing and is simpler.
• Trusting push alone. A message can be lost or arrive twice, so keep a catch-up pull and remove duplicates.
• Pushing to every follower of a very big account. One post can take minutes of work (4.8 minutes above).
• Forgetting that a receiver behind a firewall cannot accept a push that the sender starts. It can still receive over a connection that it opened itself.

Sources

• Stripe webhooks (retries for up to three days; events may arrive out of order): https://docs.stripe.com/webhooks (opens in a new tab) (checked 26 Oct 2026).
• All viewer counts, timings and server speeds are assumptions made for teaching. The calculations come from them.