Arquitectura · 23 de octubre de 2026 · Daniel Murillo
WebSockets, SSE y Webhooks: comunicación más allá de REST
No toda app necesita un canal bidireccional permanente. Cuándo usar WebSockets, SSE o Webhooks según quién inicia el evento.
No todas las aplicaciones necesitan una conexión bidireccional permanente. La mejor opción depende de quién inicia la comunicación, con qué frecuencia ocurren los eventos y qué garantías necesita el sistema.
Introducción
REST funciona muy bien para solicitudes y respuestas: el cliente pide un recurso y el servidor devuelve un resultado. Pero algunas aplicaciones necesitan actualizaciones en vivo, entrega de eventos o notificaciones entre sistemas.
WebSockets, Server-Sent Events (SSE) y Webhooks resuelven problemas relacionados, pero no son equivalentes. WebSockets mantiene un canal bidireccional; SSE permite que el servidor envíe eventos al navegador; Webhooks notifica a otro sistema mediante una solicitud HTTP cuando ocurre un evento.
1. WebSockets: comunicación bidireccional
WebSockets establece una conexión persistente que permite que cliente y servidor envíen mensajes sin iniciar una solicitud HTTP nueva para cada intercambio.
Casos frecuentes:
- Chats.
- Juegos multijugador.
- Edición colaborativa.
- Notificaciones interactivas.
- Paneles operativos con cambios frecuentes.
La conexión persistente puede reducir la sobrecarga de intercambios repetidos, pero no garantiza baja latencia por sí sola. El servidor sigue teniendo que procesar mensajes, consultar datos y distribuir eventos.
Escalabilidad y backpressure
Miles de conexiones abiertas consumen recursos. Una arquitectura robusta debe gestionar límites de conexión, memoria, heartbeats, reconexiones y distribución de mensajes entre instancias.
Backpressure es importante cuando se producen mensajes más rápido de lo que el cliente puede procesarlos. Sin límites, las colas pueden crecer y provocar presión de memoria y latencias cada vez mayores.
Entrega y recuperación
WebSockets no garantiza por sí mismo que la aplicación tenga persistencia de mensajes, confirmación de procesamiento o recuperación de eventos perdidos durante una desconexión.
Si el negocio necesita esas garantías, hay que diseñar identificadores de eventos, confirmaciones, almacenamiento, reanudación y reglas para evitar duplicados.
Compresión
La extensión permessage-deflate puede comprimir mensajes si cliente y servidor la negocian. No siempre conviene: comprimir mensajes pequeños puede añadir trabajo innecesario y hay consideraciones de seguridad cuando se mezclan datos sensibles con contenido controlado por un atacante.
2. SSE: eventos del servidor al cliente
Server-Sent Events permite que un servidor envíe eventos al navegador mediante una conexión HTTP persistente.
Es apropiado para:
- Progreso de una tarea larga.
- Logs en vivo.
- Notificaciones del servidor.
- Actualizaciones de estado.
- Paneles que reciben datos, pero no necesitan un canal bidireccional constante.
El cliente puede abrir un flujo SSE y el servidor enviar eventos a medida que están disponibles. Para enviar comandos al servidor, el cliente puede utilizar solicitudes HTTP convencionales.
SSE suele ser más sencillo que WebSockets cuando la comunicación es esencialmente unidireccional. Aun así, hay que comprobar los límites de conexiones, los timeouts de proxies, el buffering y el comportamiento de reconexión de la infraestructura.
3. Webhooks: notificaciones entre sistemas
Un Webhook es un patrón de integración. Cuando ocurre un evento, un sistema envía una solicitud HTTP a una URL registrada por otro sistema.
Por ejemplo, un proveedor de pagos puede notificar que una transacción cambió de estado. El sistema receptor procesa el evento y actualiza su dominio.
Los Webhooks no necesitan una conexión bidireccional permanente. El emisor inicia una solicitud cuando tiene algo que notificar.
Diseñar Webhooks robustos
Una entrega puede fallar temporalmente o repetirse. Por eso conviene incluir:
- Autenticación o firmas verificables.
- Reintentos con backoff y límites.
- Idempotencia para procesar duplicados de forma segura.
- Identificadores de evento.
- Timeouts.
- Registro de entregas.
- Mecanismos para reintentar manualmente.
No se debe asumir que un Webhook se entrega exactamente una vez. El diseño del receptor debe tolerar duplicados y retrasos.
4. Comparación práctica
| Necesidad | Opción habitual | Por qué |
|---|---|---|
| Crear, leer, actualizar o eliminar recursos | REST | Modelo simple de solicitud y respuesta |
| Cliente y servidor intercambian mensajes continuamente | WebSockets | Canal bidireccional |
| El servidor transmite actualizaciones al navegador | SSE | Flujo HTTP unidireccional |
| Un sistema notifica un evento a otro | Webhooks | Entrega basada en eventos mediante HTTP |
| Mensajería entre dispositivos y servicios IoT | MQTT puede encajar | Publicación y suscripción ligera |
Estas opciones pueden coexistir. Por ejemplo, una aplicación puede utilizar REST para consultar datos, SSE para mostrar el progreso de una operación y Webhooks para integrar un proveedor externo.
5. Latencia, caché y estado
WebSockets no debe elegirse únicamente porque se espera que sea más rápido. Si los cambios ocurren cada varios minutos, una solicitud HTTP periódica o SSE puede ser suficiente y más sencilla de operar.
La caché también tiene un papel distinto según el patrón. En REST, los recursos pueden aprovechar caché HTTP. En SSE y WebSockets, normalmente se necesita gestionar el estado y los eventos en la aplicación. Los Webhooks suelen requerir persistencia y reintentos más que caché de respuestas.
6. Cómo elegir
Elige WebSockets si realmente necesitas mensajes en ambas direcciones y eventos frecuentes. Elige SSE cuando el flujo vaya principalmente del servidor al cliente. Elige Webhooks cuando otro sistema deba recibir una notificación sin mantener una conexión permanente.
Antes de decidir, considera frecuencia de eventos, cantidad de clientes conectados, tolerancia a desconexiones, necesidad de persistencia, seguridad y capacidad operativa.
Conclusión
WebSockets, SSE y Webhooks existen para necesidades diferentes. No son sustitutos universales de REST y tampoco compiten exactamente entre sí.
La decisión correcta depende de la dirección del flujo, la frecuencia de los eventos y las garantías que necesita el negocio.
No uses una conexión permanente si solo necesitas una notificación ocasional; no uses polling constante si un flujo de eventos resuelve el problema de manera más sencilla.
Si el aviso debe llegar con la app cerrada o en segundo plano, WebSockets y SSE no bastan: necesitas un canal push del sistema operativo o del navegador. Eso es otra capa.
En esta serie
- REST: cómo diseñar y optimizar una API
- REST vs GraphQL
- gRPC vs REST
- WebSockets, SSE y Webhooks (esta nota)
- Caché y compresión
- Benchmarks y decisiones de arquitectura