Card 07/ 10
Choosing How Updates Reach the Other Side
Who needs to send, how often, and who is on the other end decide it.
Choosing among polling, server-sent events, WebSockets and webhooks comes down to three questions about the feature: who is on the other end, who needs to send, and how soon the news must arrive. Answer them in that order, and one pattern is left.
When The other end is a server, and it has the news
, chooseWhen Both sides send often
, chooseWhen Only the server sends, and news must arrive at once
, chooseWhen Only the server sends, at once, but the path carries nothing but plain requests
, chooseWhen A delay of a few seconds is fine
, choose
| Feature | Who sends | How soon | Pattern |
|---|---|---|---|
| Chat between users | Both sides | At once | WebSockets |
| Live match score | Server only | At once | Server-sent events |
| Report export status | Server only | Within seconds | Short polling |
| Payment confirmed by the provider | Another server | At once | Webhook |
The common mistake. WebSockets are chosen for every live feature because they can do everything. For a live score they add a connection the client never sends on, with no built-in resume, where server-sent events would reconnect and resume by themselves.
The other common mistake. Polling the payment provider every few seconds to learn whether a charge went through. The provider knows the moment it happens, and a webhook tells you then, with no wasted requests.
Mixing is normal. One product often uses several: WebSockets in the chat, server-sent events on a dashboard, webhooks from its payment provider, and polling on an export page. Each feature gets the cheapest pattern that meets its own need.
So choose per feature, by who is on the other end, who sends, and how soon, and pick the simplest pattern that answers all three.
← → move through sections and cards