Polling vs Long Polling vs SSE vs Webhooks (System Design)

How updates reach a client or another server: short polling, long polling, Server-Sent Events and webhooks compared with sequence diagrams, a failure lab…

Polling, long polling, SSE and webhooks: common questions

What is the difference between polling and long polling?

Polling asks the server on a fixed timer and usually gets “no change”. Long polling sends one request that the server holds open until there is news or a timeout, answers, and the client immediately asks again. Long polling delivers news in about one round trip; polling delivers it at the next tick.

When should I use Server-Sent Events instead of WebSockets?

When only the server needs to push: order tracking, live scores, notifications, progress, streaming AI answers. SSE is plain HTTP with automatic reconnect and Last-Event-ID resume. Use WebSockets when the client also sends messages often, such as chat typing, cursors or games.

How are webhooks different from polling or SSE?

Webhooks are server to server: another company’s system POSTs an event to a URL on your server when something happens. Browsers cannot receive webhooks. Verify the signature, deduplicate by event ID because providers retry, answer 2xx quickly, and process the event from a queue.

Related chapters

Keep learning

Previous: Message Queue vs Pub/Sub vs Kafka: Differences
Next: API design in System Design
All System design chapters

Overview

Picked up 2 min away Long polling Server-Sent Events Your server = DOWN[0] && t seen && e.t Nothing between polls One waiting request per client = DOWN[0] && e.t = DOWN[0] && b One open stream per client Nothing. Each event is one short POST your server down network down 200 OK back message with news empty answer server holding the request Poll every Poll interval Your server is down Network drops ▶ Play the minute Show all One minute of a food order HTTP requests (connects) POSTs to you HTTP requests Empty answers Average delay Updates seen none lost Server keeps open When each status change reached the other side not delivered within the minute ≈ one round trip heartbeats only pings only 1 / 10 min 1 / min 10 / min People watching an order Status changes per person Update rate Requests per second Answers with no news Connections held open Who starts each message Client, on a timer Server, over a stream the client opened The provider’s server calls yours Either side Client pulls Client pulls (feels like push) Server → client only Server → server Both ways A short request each time One held request, reopened after every answer One long-lived HTTP response One short POST per event One upgraded TCP connection Up to the interval (half on average) About one round trip Wasted work Empty answers when news is rare A timeout answer every 20–60 s Heartbeats only Pings only Catching up after a gap The next poll returns current state Send a since cursor Last-Event-ID replays missed events Build it yourself Works from a browser Yes (EventSource) No: needs a public HTTPS endpoint Typical use Dashboards, job status, anything checked every 30 s Live scores, notifications, progress, AI token streaming Payments, Git pushes, store orders Chat, games, shared editing, cursors system design · core concepts · real-time updates Polling vs long polling vs SSE vs webhooks: how the other side hears about a change The server is always the first to know: the payment cleared, the rider picked up the food, the build finished. The question is how that news reaches whoever cares. You can keep asking (polling), ask and wait (long polling), keep a line open (Server-Sent Events), or have the other server call you (webhooks).

1. Four answers to “has anything changed?”

One running example: a food order. In one minute its status changes five times. A browser wants to show each change as soon as it happens. Ask every few seconds. Simple and stateless, but most answers are “no change”, and news waits for the next ask. Long polling pull, held Server-Sent Events Open one HTTP response that never ends. The server writes a few lines each time something changes. push to browser Give another company a URL. When something happens on their side, their server POSTs it to yours. push to server client decides when to ask Held pull client asks, server decides when to answer server decides when to send Moving right, delay and wasted requests drop, and the server takes on more state: held requests or open connections.

Polling, every 5 s

Six requests, two with news. “Picked up” happens at 0:29 and waits for the next poll.

Server-Sent Events

One request opens the stream. Each change is a push down the same connection. Small ticks are heartbeats.

Webhooks

The arrows point the other way: the provider calls your server once per event, and your server answers 200 OK.

3. Polling: the simplest thing that works

Plain HTTP that every proxy, cache and load balancer understands. Stateless servers. Easy to debug. If a request fails, the next one simply catches up. Delay is up to the interval. Load grows with clients ÷ interval, not with how much actually changes. Halve the delay and you double the requests. Make empty answers cheap with an ETag and 304 Not Modified, and add random jitter to the interval so a million clients do not all ask in the same second.

4. Long polling: ask, then wait for news

The answer leaves the moment the change happens, over ordinary HTTP. The since cursor Changes that land while the client is reconnecting are not lost: the next request returns them at once. Timeouts on the path Keep the hold shorter than every idle timeout in between. AWS ALB and Nginx both default to 60 s. One request per message Every update costs a full request and response, headers included. Bursts mean many round trips. Held requests are state Each waiting client ties up a connection, and the server must wake the right one when news arrives. Mostly a fallback today Libraries such as Socket.IO used it when WebSockets were blocked. New designs usually pick SSE.

5. Server-Sent Events: one response that never ends

The browser opens a normal GET. The server answers with Content-Type: text/event-stream and keeps writing. Each message is a few text lines ended by a blank line. Verify the signature Anyone can POST to a public URL. Check the HMAC over the raw body, and reject old timestamps to stop replays. Idempotent by event ID Retries mean duplicates. Store each event ID with a unique constraint and skip ones you have seen. Answer first, work later Do slow work in a queue. A slow handler times out, the provider retries, and now you have duplicates. Events can be lost or out of order. Re-fetch the object from the provider’s API, and run a periodic poll as a safety net.

7. Lab: one minute of a food order

Pick a technique and press play. Then change the poll interval and watch requests climb, or drop the network for seven seconds and see which ones lose news, which ones catch up, and how late.

10. In the interview

The requirement says Reach for Polling with ETags and jitter. Say why it is enough. SSE (order tracking, live scores, notifications, progress bars) Both sides send often: typing, cursors, game moves Streams are blocked by a corporate proxy, or clients are old Long polling as the fallback Another company’s system must tell yours Webhooks, plus a reconciliation poll The app is closed or in the background on a phone None of these: mobile push (APNs, FCM) The follow-up: which server holds the connection? “Use WebSockets” for everything If only the server talks, SSE is simpler: plain HTTP, automatic reconnect and resume. Pick WebSocket when the client also sends often. Push is not delivery Connections drop. Every push design needs a way to catch up: a since cursor, Last-Event-ID, or a fresh fetch of current state on reconnect. Polling is not wrong For an admin dashboard refreshed every 30 s, polling is cheaper to build and run than a fleet holding open connections. ★ Remember Polling asks on a timer: simple, but delay is the interval and most answers are empty. Long polling asks and waits: near-instant over plain HTTP, one request per message. SSE keeps one response open and pushes text down it, with reconnect and Last-Event-ID built in. Webhooks are server to server: verify the signature, dedupe by event ID, answer fast, reconcile.

Go deeper

Group chat (case study): fan-out over open connections · Queues, pub/sub and logs · Proxies and load balancers · Idempotency keys · REST, GraphQL or RPC

More courses

Jobs, linked to lessons — Browse jobs where every requirement links to the chapter that teaches it. See how ready you are, how long the gap takes to close, and which listings look stale.
Match a job post to courses — Paste a job post. Each skill is matched to a track here and put in learning order, foundations first.
React from open source with patterns — Patterns extracted from Material UI, Radix, React Aria, React Hook Form, Redux Toolkit, TanStack, and Next.js — not slides about hooks.
Database in depth — How a query becomes work. Indexes, isolation, locks, and the plans that explain why a page is slow — not an ORM tour.
Build a real API with NestJS — One ticket-booking API, built in order: a plain Node server first, then NestJS modules, validation, a real database, and the features real clients lean on.
Microservices — Microservice patterns one diagram at a time: how to split a monolith, how services talk, and how data stays consistent without distributed transactions.
Kafka — A beginner-to-senior path through event logs, reliable delivery, production operations, and disaster recovery.
AI engineering for software engineers — Eight free reads, in order, for software engineers moving into AI: when to build an agent, how to build one, how to test it, and how the model works underneath.
Frontend system design — How a UI is sliced when it is a product, not a page: ownership of state, cache, routes, and what happens when the network lies.
TypeScript in depth — The type system as a design tool. Inference, narrowing, generics, and the errors that mean the model is wrong — not a catalog of utility types.
CSS in depth — See the box, then the page. Visual chapters from the box model through Flexbox surprises, Grid, selectors, and units, then backgrounds, shapes, and visual effects, each with a playground.
Accessibility — Foundations first (WCAG in plain words, semantic HTML, lists, alt text), then hands-on HTML labs, a full pass of WAI-ARIA 1.3, and a final fix-the-page challenge.
Docker — What an image is, why layers cache, and how containers find each other on a network.
Redis — Fifteen Redis patterns, one picture each: cache, session, lock, counter, rate limiter, queue, and when Redis is the wrong tool.
Kubernetes — Kubernetes from zero to operators: why it exists, Pods, Deployments and Services, then configuration, networking, storage, scheduling, scaling and security.