Aplicações modernas esperam dados em tempo real: chats que entregam mensagens instantaneamente, dashboards que atualizam métricas sem refresh, notificações que aparecem no momento do evento. Polling periódico (requisitar a cada N segundos) é a solução ingênua — funciona, mas desperdiça servidor e entrega dados com delay. WebSockets e Server-Sent Events são as soluções reais, cada uma para um caso de uso específico.
WebSockets: comunicação bidirecional full-duplex
WebSocket é um protocolo full-duplex sobre TCP: uma única conexão persistente permite envio de mensagens em ambas as direções simultaneamente, sem overhead de HTTP headers a cada mensagem. O handshake inicial é uma requisição HTTP que é “upgradada” para WebSocket — o servidor responde com 101 Switching Protocols e a partir daí é mensageria pura. Latência de mensagem cai para 1-5ms versus 50-200ms de polling HTTP, e o overhead por mensagem é de apenas 2-10 bytes de framing versus centenas de bytes de headers HTTP.
No browser, a API WebSocket é simples: new WebSocket('wss://...') abre a conexão, onmessage recebe dados, send() envia. No servidor, bibliotecas como Socket.IO (Node.js) adicionam reconexão automática, rooms para broadcast seletivo, namespaces para isolar canais, e fallback para long-polling em ambientes que bloqueiam WebSockets. ws é a alternativa mais leve, sem abstrações extras. No lado Python, websockets e aiohttp suportam WebSocket com async/await nativo. A escala horizontal requer que todas as instâncias do servidor compartilhem estado das conexões — Redis Pub/Sub ou um message broker como RabbitMQ coordinam o broadcast entre instâncias.
Server-Sent Events: o unidirecional esquecido
Server-Sent Events (SSE) é uma especificação HTTP nativa para streaming de eventos do servidor para o cliente — sem upgrade de protocolo, sem biblioteca adicional, sem configuração especial. O servidor mantém uma resposta HTTP aberta com Content-Type: text/event-stream e envia mensagens em formato de texto simples. O browser gerencia reconexão automática, IDs de evento para retomar de onde parou após reconexão, e a API EventSource é nativa em todos os browsers modernos sem polyfill.
A vantagem do SSE sobre WebSockets para comunicação unidirecional (servidor → cliente) é a simplicidade: funciona através de proxies e load balancers HTTP sem configuração especial, compressão gzip funciona nativamente, e o modelo mental é o de uma resposta HTTP longa. Para dashboards de métricas, feeds de atividade, notificações e atualizações de status, onde o cliente não precisa enviar dados de volta, SSE é a escolha mais simples e operacionalmente mais barata. Com HTTP/2, múltiplos streams SSE compartilham a mesma conexão TCP sem overhead adicional por stream.
Quando usar cada um
WebSockets são a escolha quando a comunicação é genuinamente bidirecional: chats, jogos multiplayer, editores colaborativos (como Google Docs), e ferramentas de whiteboard em tempo real. Se o cliente enviará mensagens com frequência e brevidade, WebSocket evita o overhead de HTTP por mensagem. Para sistemas de trading onde cada milissegundo importa, o protocolo WebSocket com mensagens binárias (ArrayBuffer) elimina o overhead de serialização JSON e entrega dados de mercado com latência mínima.
SSE são a escolha para streaming unidirecional: logs em tempo real de deploys (típico em plataformas como Heroku/Vercel), progressão de tarefas longas que atualizam a UI, feeds de notificações, e streaming de respostas de LLMs (o efeito de texto sendo “digitado” que você vê no ChatGPT é SSE). Se você está construindo com Next.js ou qualquer framework que rode sobre HTTP, SSE se integra sem esforço adicional — é literalmente uma response com headers corretos e writes incrementais. Combine os dois onde faz sentido: SSE para downstream (servidor → cliente), requests HTTP normais para upstream (cliente → servidor).
Segurança e autenticação
WebSockets não enviam cookies automaticamente no handshake além do caminho inicial — autentique na primeira mensagem ou via token na URL de conexão (cuidado com logs que capturariam o token). CSRF não é uma preocupação nativa de WebSockets, mas valide a Origin header no handshake para prevenir conexões de origens não autorizadas. Para SSE, cookies e headers de autorização funcionam normalmente no EventSource — use o mesmo middleware de autenticação que suas rotas HTTP normais.
Rate limiting em conexões WebSocket é crítico: um cliente malicioso abrindo 10.000 conexões simultâneas pode esgotar file descriptors do servidor. Limite conexões por IP, implemente backoff exponencial no servidor para reconexões frequentes, e use timeouts para desconectar clientes idle. Para SSE, o próprio limite de conexões HTTP do servidor protege naturalmente. Monitore: número de conexões ativas, mensagens por segundo, e memory usage por conexão — um memory leak em handler WebSocket que acumula listeners é sutil e destrutivo em escala.
Tem um projeto em mente?
Somos especialistas em transformar ideias em produtos digitais. Apps, sites, automações e IA — vamos construir juntos.
