Webhooks, WebSockets or polling: pick the right one
Polling 20 matches costs 43,200 requests on a Saturday. A socket costs one connection. Here is which transport fits which job, with the request math.
GOAL API· Engineering
Three ways to get a goal into your app
- Polling: you ask on a timer
- WebSocket: we push over an open connection
- Webhooks: we POST to your server
Each one fits a different job. Picking wrong costs you quota, latency, or reliability.
The request math
One match lasts about 2 hours. Say you poll every 10 seconds.
- 720 requests per match
- 3 goals on average
- 717 requests returned no new information
Now watch 20 matches on a Saturday. Polling every 10 seconds across a 6 hour window costs 43,200 requests.
The same 20 matches over one socket cost 1 connection and 1 token request.
On the Pro plan at 10,000 requests per day, polling 20 matches breaks your quota before the afternoon ends. A socket leaves the quota untouched.
When polling is the right answer
Polling is not always wrong. Reach for polling when:
- You refresh a standings table once a minute
- You run a nightly job over yesterday results
- You build a prototype and want fewer moving parts
Polling has one real advantage. Nothing to reconnect, nothing to verify, no inbound traffic to your server.
When to open a WebSocket
Use a socket when a human stares at the screen and expects the score to move.
- Live score pages
- Match centres
- In play dashboards
A socket needs a client that reconnects with backoff. Budget for the reconnect logic before you start.
When to send webhooks
Use webhooks when your backend reacts to events with no user present.
- Send a push notification on a goal
- Settle a prediction game when a match finishes
- Write results into your own database
- Trigger a Slack message for a specific team
Webhooks reach your server whether or not anyone has your app open. A socket only helps while a client stays connected.
Straight comparison
| Polling | WebSocket | Webhooks | |
|---|---|---|---|
| Direction | You ask | We push | We push |
| Needs a public URL | No | No | Yes |
| Survives a closed browser | No | No | Yes |
| Quota cost | High | Low | One per delivery |
| Latency | Up to your interval | Under a second | Seconds |
| Extra work | None | Reconnect logic | Signature checks, idempotency |
What most teams end up running
A live scores product usually runs two of the three:
- A socket for the screen
- Webhooks for the database and notifications
- REST on page load, and after every reconnect, to fill gaps
Skip the gap fill and you ship a page showing 1-0 for a match already finished 3-1.
