Real-time updates: polling, WebSockets, SSE and push
An order changes status on the server. How does the screen in a store, or on a partner shop owner's phone, find out? This lesson compares the five ways to get news from a server to an app, and shows how to keep them working across several servers, flaky networks and closed apps.
By the end you can
- Compare short polling, long polling, Server-Sent Events, WebSockets and mobile push
- Pick the right one from how fresh, how often, and which direction the updates go
- Build an SSE endpoint in NestJS that resumes from the last event id
- Scale a Socket.IO gateway across servers with the Redis adapter
- Send a push notification with firebase-admin and clean up dead tokens
The everyday picture
You order food at a busy restaurant. There are several ways to find out it is ready. You can walk to the kitchen every minute and ask "is mine ready?" (polling). You can ask once and the cook says "wait here, I'll tell you", and you stand there until it is ready (long polling). The restaurant can call token numbers over a loudspeaker, so you just listen (Server-Sent Events). You can keep a phone line open to the kitchen, so both of you can talk any time (WebSocket). Or, if you stepped outside to buy a drink, the restaurant can send an SMS to your phone (push notification).
Each works. They differ in how much walking (requests) they need, how fast you hear the news, who can speak, and whether they reach you after you have left the building.
Polling: ask again and again
Short polling is a timer in the app: GET /orders/5512 every 5 seconds. It is plain HTTP, so it works through every proxy and firewall, it can use HTTP caching and ETags (Caching), and it needs nothing special on the server. Its costs are easy to compute. News arrives on average half an interval late (2.5 s with a 5-second timer) and at worst a full interval late. And most requests return "nothing new": 300 stores polling every 5 seconds is 60 requests per second, all day, even when nothing happens.
For a goods-received (GRN) dashboard that changes a few times an hour, or a screen with a handful of users, polling every 30 to 60 seconds is the right answer. Do not let anyone talk you out of it with "it's not real-time".
Long polling fixes the delay. The server does not answer until there is news, or until a timeout of 20 to 30 seconds passes with nothing. The moment the app gets an answer, it sends the next request. News arrives almost instantly and the request count falls. The cost is that every waiting client holds an open request on the server, and every proxy timeout on the way (Load balancers) must be longer than the hold time.
Quick check
600 Rider app phones poll for new orders every 10 seconds. How many requests per second is that, even when nothing changes?
600 phones ÷ 10 seconds = 60 requests per second, all day. 600 would be the rate if each phone polled every second. This steady cost is why polling suits small audiences or slow timers.