Webhook, WebSocket or periodic polling: which one to use in each case

Published on 2026-09-12 by frfrand

Tres formas de enterarse de que algo pasó, con costos muy distintos. Cuatro preguntas que resuelven la decisión sin discutir arquitectura.

The three solve the same underlying problem: finding out that something happened. They differ in who speaks first, how much it costs to maintain it, and what happens when something fails.

The three, in one line each

Periodic polling. You ask every so often. Simple, nothing to keep alive.

Webhook. The other service calls you when something happens. No permanent connection, but you need a public address.

WebSocket. An open connection in both directions. Minimum latency, in exchange for keeping that connection per client.

The four questions

1. Who starts the conversation?

If the one who knows something new is an external service (a payment platform, GitHub, WhatsApp), the answer is webhook. No discussion: it's the mechanism those services offer.

If the one who knows something new is your own backend and the recipient is a browser, look at the other two.

2. How often?

Events per hour → webhook or periodic polling. Events per second → WebSocket.

Keeping a thousand open connections to report something that happens three times a day is expensive in maintenance and resources.

3. Is a round trip needed?

If the client only receives (notifications, task progress, a panel that updates), Server-Sent Events is usually better than a WebSocket: it runs over normal HTTP and the browser reconnects on its own.

WebSocket is justified when the client also sends frequently: a chat, a collaborative editor, a game.

4. What happens if it arrives late?

If a thirty-second delay changes nothing, periodic polling and done. It's the most boring option and the one that breaks the least.

Why periodic polling isn't the losing option

It has a bad reputation and deserves a defense, because in production it wins more often than admitted:

• No connections to maintain nor reconnections to implement.
• It recovers on its own: if a query fails, the next one brings everything up to date.
• It scales without thinking: any server can respond, there's no need for the client to always return to the same one.

When volume is the problem, there are intermediate ways: request only what changed since the last time, or leave the request waiting until there's news (long polling), which gives near real-time latency with much less complexity.

The classic mistake

Choosing WebSockets because it sounds modern, and discovering three months later that you have to solve: reconnection, recovery of lost messages while you were disconnected, sticky sessions on the load balancer, open file descriptor limits, and a Redis to distribute among servers.

All that is real and permanent work. It's worth it when the product needs it. It's not worth it to update a counter every minute.

What's most common in real life

Most systems use two of the three, not just one.

A typical example: webhooks to find out what's happening outside (payments, messages, repositories), WebSocket or SSE for the part of the interface that really needs to be seen live, and periodic queries for everything else.

Choosing a single technology for everything is the shortest path to fighting with it.