Bun Real-Time — Parte 1: WebSocket vs Server-Sent Events
Quando falamos em aplicações real-time, logo vem à cabeça dos devs o bom e velho p̵o̵l̵l̵i̵n̵g̵ WebSocket. Mas será que o WebSocket é…
Bun Real-Time — Parte 1: WebSocket vs Server-Sent Events
Websocket Vs Server Send Events
Quando falamos em aplicações real-time, logo vem à cabeça dos devs o bom e velho p̵o̵l̵l̵i̵n̵g̵ WebSocket. Mas será que o WebSocket é realmente a melhor opção para tudo?
Vivemos em um mundo onde as aplicações estão cada vez mais vivas, comunicando-se entre si e com os usuários. Garantir essa comunicação com excelência está se tornando primordial. Os agentes de IA entraram com peso para a lista de sistemas que demandam respostas em tempo real, juntando-se aos tradicionais dashboards, chats e notificações.
Entender qual tecnologia utilizar no backend pode ajudar você e sua empresa a economizarem tempo, dinheiro e alguns fios de cabelo com infraestrutura. Pensando nisso, hoje vamos colocar no ringue: WebSocket (WS) vs Server-Sent Events (SSE).
🛤️ WebSocket: A Via de Mão Dupla
O WebSocket é um protocolo de comunicação Full-Duplex (input e output simultâneos de dados). A sua comunicação se dá inicialmente através de um túnel TCP persistente entre o cliente e o servidor. Assim que o handshake HTTP acontece, o protocolo sofre um upgrade e muda para ws:// ou wss://.
Características:
- Comunicação Bidirecional: Servidor e cliente podem enviar dados a qualquer momento.
- Stateful (Com Estado): A conexão fica alocada a um servidor físico/instância específica.
- Baixíssimo Overhead: Após a conexão ser aberta, os pacotes trafegam “limpos”, sem os pesados cabeçalhos do HTTP tradicional.
Vantagens ✅
- Velocidade: Latência mínima absoluta (sub-50ms).
- Frequência: Ideal para envios de altíssima frequência (centenas de mensagens por minuto de ambos os lados).
Desvantagens ❌
- Escalabilidade Complexa: Se você tiver 3 instâncias da sua API atrás de um Load Balancer, o Usuário A (Instância 1) não consegue conversar com o Usuário B (Instância 2) sem que você adicione uma camada extra na arquitetura (como um Redis Pub/Sub) para sincronizar os servidores.
- Gestão Manual de Quedas: Se a internet do usuário oscilar, a conexão fica “zumbi”. É preciso criar um sistema de Ping/Pong (Heartbeat) manual no cliente e no servidor para detectar a queda e forçar a reconexão. Esse problema se agrava em redes corporativas, onde proxies e firewalls podem bloquear ou derrubar as conexões silenciosamente (isso sem falar de redes mal implementadas).
📡 Server-Sent Events (SSE): O Alto-Falante
O SSE é uma especificação nativa do HTML5 que permite ao servidor enviar um fluxo contínuo de dados (texto/JSON) para o cliente através de uma única conexão HTTP (text/event-stream).
Nota: A palavra “stream” pode causar um pouco de confusão, levando a pensar que é assim que plataformas como YouTube e Netflix transmitem seus conteúdos em vídeo. Para vídeos pesados, empresas de streaming usam outros protocolos, como HLS e DASH, mas isso fica pra outro papo ;)
Características:
- Unidirecional: Apenas o servidor fala. Se o cliente quiser enviar uma informação, ele faz uma requisição REST normal (POST, PUT, etc.).
- Puro HTTP: Trafega sobre o bom e velho protocolo HTTP de sempre.
Vantagens ✅
- Resiliência Nativa: O navegador lida com as quedas automaticamente através da API
EventSource. Se a internet piscar, ele tenta reconectar sozinho, sem código extra. - Infraestrutura Amigável: Como é puramente HTTP, Load Balancers padrão processam o SSE sem engasgar, facilitando muito o scale-out (escalabilidade horizontal).
Desvantagens ❌
- Como é unidirecional, o cliente não pode responder pelo mesmo canal “barato” (exige requisições HTTP paralelas).
- No antigo HTTP/1.1, os navegadores limitavam a aplicação a cerca de 6 conexões SSE abertas por domínio. (Hoje isso já está muito mitigado: se a sua infra usa HTTP/2, o limite sobe para 100+ via multiplexação).
📊 Como ficam os custos de infraestrutura?
Quando testamos na nossa máquina local (localhost), tudo é rápido. Mas o que acontece quando sua aplicação atinge 10.000 usuários simultâneos? A diferença arquitetural entre manter um estado contínuo (WebSocket) e enviar um fluxo de texto (SSE) cobra o seu preço na AWS/GCP.
Nota: O WebSocket não é o “vilão” dos custos. Ele consome mais recursos justamente porque entrega um túnel bidirecional de altíssima performance. Tentar recriar esse nível de interação (como um jogo multiplayer ou cursores na tela do Figma) usando SSE + REST exigiria gambiarras pesadas — como o cliente disparar dezenas de requisições POST por segundo — , o que derrubaria o seu servidor muito mais rápido. O WebSocket cobra mais caro na infraestrutura porque faz coisas que o SSE não foi feito para fazer.
Aqui está o comparativo técnico de consumo no servidor:
🧠 Uso de Memória RAM (por conexão)
- WebSocket: Alto. O servidor precisa alocar memória para manter o estado da conexão TCP, os buffers de leitura/escrita bidirecionais e o contexto daquele usuário.
- SSE: Muito Baixo. É tratado pelo servidor apenas como uma resposta HTTP comum que está “demorando” para ser fechada.
⚙️ Carga de CPU (Overhead)
- WebSocket: Média/Alta. O protocolo exige framing (cada pacote tem um cabeçalho binário próprio) e os dados enviados pelo cliente precisam ser “desmascarados” (data unmasking) por motivos de segurança, consumindo ciclos de CPU constantemente.
- SSE: Quase Zero. O servidor apenas faz o flush (empurra) de strings de texto puro direto para o socket que já está aberto. Não há decodificação complexa.
❤️ Manutenção da Conexão (Heartbeat)
- WebSocket: Manual e Custosa. Exige Pings/Pongs constantes da sua aplicação para evitar que a conexão morra (libs como o Socket.io abstraem isso, mas o custo computacional continua lá). Isso mantém a CPU do servidor e do celular do usuário acordadas o tempo todo.
- SSE: Nativa do SO. Usa os mecanismos padrão de rede do sistema operacional e do navegador. É muito mais amigável para a bateria de dispositivos móveis.
🚪 Limites de Conexão (File Descriptors)
- WebSocket: Exige uma porta TCP real aberta por cliente. Escala bem, mas pode esgotar portas rapidamente no servidor em sistemas que não estão devidamente tunados.
- SSE: Com a mágica da Multiplexação do HTTP/2, 100 abas do seu dashboard abertas no navegador podem compartilhar uma única conexão TCP física.
💸 Custo de Escalabilidade (Load Balancing)
- WebSocket: Complexo e Sensível. Como exige um upgrade de protocolo, ele dificulta a vida dos balanceadores. Muitas vezes força você a configurar Sticky Sessions (Sessões Pegajosas) ou apelar para o balanceamento de Camada 4.
- SSE: Simples e Robusto. Por ser tráfego HTTP puro, balanceadores de Camada 7 (Nginx, ALB, Cloudflare) tratam nativamente, sem exigir configurações exóticas. (Nota: Em múltiplas instâncias, você ainda precisará de um Pub/Sub como o Redis para propagar os eventos internamente, mas a camada de rede externa continua extremamente simples).
🏆 Quando usar um ou o outro?
A pergunta valendo R$ 1.000.000,00!
Use WebSockets se o seu projeto for:
- Um jogo Multiplayer em tempo real (posição de jogadores x/y em alta taxa de quadros).
- Ferramentas de colaboração simultânea (ex: desenhar junto no Figma, editar o mesmo Google Docs).
- Aplicativos de Trading / Home Broker de altíssima frequência.
- Um Chat puro onde o status de “Digitando…”, “Visualizado” e o envio instantâneo são o produto principal (ex: WhatsApp Web).
Use SSE se o seu projeto for:
- Dashboards: Atualização de gráficos, métricas e análises ao vivo.
- Feeds e Notificações: O sininho do sistema avisando que um novo ticket foi aberto.
- Streaming de IA: O famoso efeito “máquina de escrever” dos LLMs gerando texto.
- Status de Processamento: Avisar o front-end que “O vídeo está sendo renderizado: 45% concluído”.
🏁 Conclusão
A regra de ouro é simples: use a ferramenta certa para o trabalho certo. Não tenha medo de usar WebSocket quando a altíssima interatividade exigir, mas abrace a leveza e simplicidade do SSE sempre que possível.
Muito obrigado por ler até aqui! 🚀 Se este artigo te ajudou a clarear as ideias, deixe suas palmas e compartilhe com a comunidade.
E prepare o terminal, pois no nosso próximo post vamos por as mãos de código em:
👉 **Bun Real-Time — Parte 2: Implementando WebSocket com Bunjs**
Um abraço e até a próxima!
Referencias: https://www.cloudflare.com/pt-br/learning/video/what-is-mpeg-dash/
메타데이터
- post_id
- 439d904dadff
- slug
- bun-real-time-parte-1-websocket-vs-server-sent-events-439d904dadff
- url
- https://medium.com/@yatadev/bun-real-time-parte-1-websocket-vs-server-sent-events-439d904dadff
- canonical_url
- https://medium.com/@yatadev/bun-real-time-parte-1-websocket-vs-server-sent-events-439d904dadff
- author_url
- https://medium.com/@yatadev
- status
- ok
- fetched_at
- 2026-06-16 19:09:56
