Long Polling, SSE, WebSockets y Webhooks: cómo elegir el patrón

Guía práctica para decidir entre cuatro patrones de comunicación en tiempo real según la dirección del flujo y el tipo de receptor.

HTTP es un protocolo dirigido por el cliente: el servidor solo responde cuando se le pregunta. Eso funciona bien hasta que las actualizaciones pueden llegar en cualquier momento. Consultar cada pocos segundos (polling) obliga a elegir entre retrasos o peticiones inútiles. En esta guía repasamos cuatro alternativas descritas en el artículo original de AlgoMaster y proponemos un método sencillo para decidir cuál encaja en tu caso.

Lo que necesitas

Basta con tener claro qué tipo de comunicación necesita tu sistema: quién envía los datos, con qué frecuencia y si el receptor es un navegador o un servidor. Si quieres profundizar, el curso System Design Fundamentals tiene un capítulo por cada patrón.

Cuatro formas de recibir datos sin esperar al siguiente sondeo.

Los cuatro patrones, en breve

Long Polling (detalle aquí): el cliente hace una petición y el servidor la mantiene abierta hasta que hay datos. Al recibir la respuesta, el cliente abre otra inmediatamente. Su gran ventaja es la simplicidad, porque usa HTTP estándar y funciona con navegadores, proxies y balanceadores existentes. Su coste: cada actualización arrastra cabeceras y autenticación, y hay un hueco entre una respuesta y la siguiente petición en el que se pueden perder eventos.

Server-Sent Events (detalle aquí): una única conexión HTTP que permanece abierta, por la que el servidor envía eventos en un formato de texto sencillo. Los navegadores lo soportan de forma nativa con EventSource y se reconectan solos. Es unidireccional: solo del servidor al cliente. Encaja con notificaciones, progreso de tareas, paneles de monitorización o texto generado por modelos de lenguaje.

WebSockets (detalle aquí): comunicación persistente y bidireccional. Empieza como una petición HTTP con Upgrade: websocket; si el servidor acepta, responde 101 Switching Protocols y ambos lados pueden enviar mensajes en cualquier momento mediante tramas ligeras. Webhooks (detalle aquí) completan el cuadro para la comunicación entre servidores.

Cómo elegir paso a paso

1. Define la dirección del flujo: ¿solo el servidor emite datos o ambos extremos necesitan enviar mensajes en tiempo real?
2. Si el servidor emite y el cliente solo escucha, empieza por SSE: es más ligero que Long Polling y se reconecta solo.
3. Si el cliente también envía con frecuencia (juegos, chats, edición colaborativa), pasa a WebSockets.
4. Si no puedes usar conexiones persistentes o tu infraestructura es muy restrictiva, recurre a Long Polling por su compatibilidad con HTTP estándar.
5. Si quien debe enterarse es otro servidor y no un navegador, valora un Webhook en lugar de mantener una conexión abierta.
6. Define cómo recuperar eventos perdidos: un identificador o cursor del último evento recibido.

Un ejemplo mínimo con SSE

El servidor responde con Content-Type: text/event-stream y cada evento lleva un id y un data, separados por una línea en blanco. En el navegador, el consumo es corto:

const events = new EventSource('/events');

events.onmessage = (event) => {
  showNotification(JSON.parse(event.data));
};

Si el servidor etiqueta los eventos con id, el navegador enviará la cabecera Last-Event-ID al reconectar, y el servidor podrá reanudar desde ese punto en lugar de empezar de cero. Con Long Polling conviene replicar la idea a mano: el cliente manda el ID del último evento recibido y el servidor devuelve primero lo pendiente antes de quedarse esperando.

Una sola conexión abierta, muchos eventos. Imagen: Unsplash — a close up of food on a table

Truco Piensa siempre en la reconexión: las conexiones largas se cortan. Con Long Polling y SSE, guarda un identificador del último evento visto; con WebSockets, tendrás que diseñar tú mismo esa recuperación. Y recuerda que mantener muchas conexiones abiertas tiene un coste en el servidor que crece con el número de clientes.

Opinión · El contexto que falta

Lo que más valoro de esta guía es que empieza por la pregunta correcta: quién envía los datos y con qué frecuencia. Antes de pensar en tecnología hay que pensar en la dirección del flujo, porque de ahí sale casi toda la decisión. Como responsable técnico, yo añadiría que la opción más simple que cubra tu caso suele ser la que menos te dará la lata de madrugada.

También me parece acertado el énfasis en la reconexión. Las conexiones largas se cortan, y diseñar desde el principio cómo recuperar lo perdido es lo que separa un prototipo de un sistema fiable. El coste de mantener conexiones abiertas, que crece con los clientes, conviene tenerlo presente al dimensionar.

Artículos relacionados de LaRebelión

Por qué el estado es lo más difícil del diseño de software y cómo domarloDeepSeek libera TileLang para chips Huawei Ascend y apunta al foso de CUDAOpenAI frena una campaña para extraer el razonamiento de sus modelos

Fuente original: blog.algomaster.io

Artículo generado mediante AI.larebelion

Kernel · Dirección de tecnología · España

«Elegir el patrón es la parte fácil; lo difícil es decidir qué pasa cuando la conexión se cae.»