28 de nov. de 2025·8 min
WebSockets vs Server-Sent Events: escolha a opção certa
WebSockets vs Server-Sent Events explicados para dashboards ao vivo, com regras simples para escolher, noções de escala e o que fazer quando conexões caem.
WebSockets vs Server-Sent Events explicados para dashboards ao vivo, com regras simples para escolher, noções de escala e o que fazer quando conexões caem.
Um dashboard ao vivo é basicamente uma promessa: os números mudam sem que você dê refresh, e o que você vê está próximo do que está acontecendo agora. As pessoas esperam que as atualizações pareçam rápidas (frequentemente dentro de um ou dois segundos), mas também esperam que a página permaneça calma. Sem piscadas, sem gráficos pulando, sem banner de "Desconectado" a cada poucos minutos.
A maioria dos dashboards não é um app de chat. Eles essencialmente empurram atualizações do servidor para o navegador: novos pontos de métrica, mudança de status, um novo lote de linhas ou um alerta. As formas comuns são familiares: um painel de métricas (CPU, cadastros, receita), um painel de alertas (verde/amarelo/vermelho), um tail de logs (eventos mais recentes) ou uma visão de progresso (tarefa em 63%, depois 64%).
A escolha entre WebSockets e Server-Sent Events (SSE) não é apenas uma preferência técnica. Ela altera quanto código você escreve, quantos casos de borda estranhos precisa tratar e quanto fica caro quando 50 usuários viram 5.000. Algumas opções são mais fáceis de balancear. Algumas tornam a lógica de reconexão e de recuperação mais simples.
O objetivo é simples: um dashboard que permaneça preciso, responsivo e que não vire um pesadelo de on-call conforme cresce.
WebSockets e Server-Sent Events mantêm uma conexão aberta para que um dashboard possa atualizar sem polling constante. A diferença é como a conversa acontece.
WebSockets em uma frase: uma conexão única e duradoura onde o navegador e o servidor podem enviar mensagens a qualquer momento.
SSE em uma frase: uma conexão HTTP de longa duração onde o servidor empurra eventos para o navegador continuamente, mas o navegador não envia mensagens de volta por esse mesmo fluxo.
Essa diferença geralmente decide o que parece natural.
Um exemplo concreto: um placar de KPIs de vendas que só mostra receita, trials ativos e taxa de erros pode rodar feliz em SSE. Uma tela de trading onde o usuário faz ordens, recebe confirmações e precisa de feedback imediato a cada ação é muito mais no formato WebSocket.
Não importa qual você escolha, algumas coisas não mudam:
O transporte é a última milha. As partes difíceis costumam ser as mesmas de qualquer forma.
A principal diferença é quem pode falar, e quando.
Com Server-Sent Events, o navegador abre uma conexão longa e só o servidor envia atualizações por esse canal. Com WebSockets, a conexão é bidirecional: navegador e servidor podem enviar mensagens a qualquer momento.
Para muitos dashboards, a maior parte do tráfego é servidor -> navegador. Pense "novo pedido chegou", "CPU está em 73%", "contagem de tickets mudou". SSE se encaixa bem porque o cliente basicamente escuta.
WebSockets fazem mais sentido quando o dashboard também é um painel de controle. Se um usuário precisa enviar ações com frequência (confirmar alertas, mudar filtros compartilhados, colaborar), mensagens bidirecionais podem ser mais limpas do que criar requisições novas o tempo todo.
Os payloads de mensagem geralmente são JSON simples de qualquer forma. Um padrão comum é enviar um envelope pequeno para que os clientes possam rotear atualizações com segurança:
{"type":"metric","name":"active_users","value":128,"ts":1737052800}
Fan-out é onde dashboards ficam interessantes: uma atualização frequentemente precisa alcançar muitos visualizadores ao mesmo tempo. Tanto SSE quanto WebSockets podem broadcastar o mesmo evento para milhares de conexões abertas. A diferença é operacional: SSE se comporta como uma resposta HTTP longa, enquanto WebSockets trocam para um protocolo separado após o upgrade.
Mesmo com uma conexão ao vivo, você ainda usará requisições HTTP normais para coisas como carregamento inicial da página, dados históricos, exports, criar/excluir ações, refresh de auth e consultas grandes que não pertencem ao feed ao vivo.
Uma regra prática: mantenha o canal ao vivo para eventos pequenos e frequentes, e use HTTP para todo o resto.
Se seu dashboard só precisa empurrar atualizações para o navegador, SSE normalmente vence em simplicidade. É uma resposta HTTP que fica aberta e envia eventos em texto conforme acontecem. Menos peças móveis significam menos casos de borda.
WebSockets são ótimos quando o cliente precisa responder com frequência, mas essa liberdade adiciona código que você precisa manter.
Com SSE, o navegador conecta, escuta e processa eventos. Reconexões e comportamento básico de retry já vêm integrados na maioria dos navegadores, então você passa mais tempo cuidando dos payloads de evento e menos tempo do estado de conexão.
Com WebSockets, você logo acaba gerenciando o ciclo de vida do socket como um recurso de primeira classe: connect, open, close, error, reconnect e às vezes ping/pong. Se tiver muitos tipos de mensagem (filtros, comandos, confirmações, sinais de presença), também precisa de um envelope e roteamento de mensagens no cliente e no servidor.
Uma boa regra prática:
SSE costuma ser mais fácil de debugar porque se comporta como HTTP normal. Você geralmente vê eventos claramente nas devtools do navegador, e muitos proxies e ferramentas de observabilidade já entendem HTTP bem.
WebSockets podem falhar de maneiras menos óbvias. Problemas comuns são desconexões silenciosas de load balancers, timeouts por inatividade e conexões "meio-abertas" onde um lado acha que ainda está conectado. Você frequentemente nota problemas só depois que usuários reclamam de dashboards desatualizados.
Exemplo: se você está construindo um dashboard de vendas que só precisa de totais ao vivo e pedidos recentes, SSE mantém o sistema estável e legível. Se a mesma página também precisa enviar interações rápidas do usuário (filtros compartilhados, edição colaborativa), WebSockets podem valer a complexidade extra.
Quando um dashboard vai de alguns visualizadores para milhares, o principal problema não é a largura de banda bruta. É o número de conexões abertas que você precisa manter e o que acontece quando alguns desses clientes são lentos ou instáveis.
Com 100 espectadores, ambas as opções parecem semelhantes. Em 1.000, você começa a se preocupar com limites de conexão, timeouts e com que frequência clientes reconectam. Em 50.000, você está operando um sistema pesado em conexões: cada kilobyte extra em buffer por cliente vira pressão de memória real.
Diferenças de escala frequentemente aparecem no load balancer.
WebSockets são conexões longas e bidirecionais, então muitos setups precisam de sessões sticky a menos que você tenha uma camada pub/sub compartilhada e qualquer servidor possa atender qualquer usuário.
SSE também é de longa duração, mas é HTTP comum, então tende a funcionar mais suavemente com proxies existentes e pode ser mais fácil de fan-out.
Manter servidores stateless geralmente é mais simples com SSE para dashboards: o servidor pode empurrar eventos de um stream compartilhado sem lembrar muito por cliente. Com WebSockets, times frequentemente armazenam estado por conexão (subscriptions, last-seen IDs, contexto de auth), o que complica o escalonamento horizontal a menos que você desenhe isso cedo.
Clientes lentos podem te prejudicar silenciosamente em ambas abordagens. Fique de olho nestes modos de falha:
Uma regra simples para dashboards populares: mantenha mensagens pequenas, envie menos frequentemente do que você acha e esteja disposto a descartar ou coalescer atualizações (por exemplo, enviar apenas o valor mais recente da métrica) para que um cliente lento não arraste todo o sistema para baixo.
Dashboards ao vivo falham de maneiras entediantes: um laptop dorme, o Wi‑Fi troca de rede, um celular passa por um túnel ou o navegador suspende uma aba em segundo plano. A escolha do transporte importa menos do que como você recupera quando a conexão cai.
Com SSE, o navegador já tem reconexão embutida. Se o stream quebra, ele tenta novamente após um pequeno atraso. Muitos servidores também suportam replay usando um id de evento (frequentemente via um cabeçalho no estilo Last-Event-ID). Isso permite que o cliente diga, "eu vi por último o evento 1042, me envie o que perdi", o que é um caminho simples para resiliência.
WebSockets normalmente precisam de mais lógica no cliente. Quando o socket fecha, o cliente deve tentar novamente com backoff e jitter (para que milhares de clientes não reconectem ao mesmo tempo). Depois de reconectar, você também precisa de um fluxo claro de resubscribe: autenticar de novo se necessário, então entrar nos canais certos e requisitar quaisquer atualizações perdidas.
O risco maior são lacunas silenciosas de dados: a UI parece bem, mas está desatualizada. Use um destes padrões para que o dashboard prove que está atualizado:
Exemplo: um dashboard de vendas que mostra "pedidos por minuto" pode tolerar uma breve lacuna se atualizar totais a cada 30 segundos. Um dashboard de trading não pode; precisa de números de sequência e um snapshot em cada reconexão.
Dashboards ao vivo mantêm conexões de longa duração abertas, então pequenos erros de auth podem perdurar por minutos ou horas. Segurança é menos sobre o transporte e mais sobre como você autentica, autoriza e expira o acesso.
Comece com o básico: use HTTPS e trate cada conexão como uma sessão que deve expirar. Se confiar em cookies de sessão, garanta que estejam com escopo correto e rotacionados no login. Se usar tokens (como JWTs), mantenha-os de curta duração e planeje como o cliente os renova.
Um pegadinha prática: o SSE do navegador (EventSource) não permite cabeçalhos customizados. Isso frequentemente empurra times para autenticação por cookie, ou colocar um token na URL. Tokens em URL podem vazar via logs e copy-paste, então se for necessário usá‑los, mantenha‑os de curta duração e evite logar query strings completas. WebSockets tipicamente dão mais flexibilidade: você pode autenticar durante o handshake (cookie ou query string) ou imediatamente após conectar com uma mensagem de autenticação.
Para dashboards multi‑tenant, autorize duas vezes: na conexão e em cada subscribe. Um usuário só deve poder se inscrever em streams que lhe pertencem (por exemplo, org_id=123), e o servidor deve impor isso mesmo que o cliente peça mais.
Para reduzir abuso, limite e monitore uso de conexões:
Esses logs são sua trilha de auditoria e a forma mais rápida de explicar por que alguém viu um dashboard em branco ou os dados de outra pessoa.
Comece com uma pergunta: seu dashboard está mais assistindo ou também falando o tempo todo? Se o navegador principalmente recebe atualizações (gráficos, contadores, luzes de status) e ações do usuário são ocasionais (mudança de filtro, confirmar alerta), mantenha o canal em tempo real unidirecional.
Depois, olhe 6 meses à frente. Se você espera muitos recursos interativos (edições inline, controles estilo chat, operações drag-and-drop) e muitos tipos de evento, planeje um canal que lide com as duas direções de forma limpa.
Então decida quão correto a visão precisa ser. Se tudo bem perder algumas atualizações intermediárias (pois a próxima atualização substitui o estado antigo), favoreça simplicidade. Se você precisa de replay exato (cada evento importa, auditorias, ticks financeiros), precisará de sequenciamento, buffering e lógica de re‑sync mais robustos, seja qual for a tecnologia.
Finalmente, estime concorrência e crescimento. Milhares de espectadores passivos normalmente te empurram para a opção que se dá bem com infra HTTP e escalonamento horizontal fácil.
Escolha SSE quando:
Escolha WebSockets quando:
Se estiver em dúvida, escolha SSE primeiro para dashboards tipicamente de leitura, e só mude quando necessidades bidirecionais se tornarem reais e constantes.
A falha mais comum começa escolhendo uma ferramenta mais complexa do que o dashboard precisa. Se a UI só precisa de atualizações servidor->cliente (preços, contadores, status de jobs), WebSockets podem adicionar peças extras com pouco benefício. Times acabam debugando estado de conexão e roteamento de mensagens em vez do dashboard.
Reconexão é outra armadilha. Uma reconexão normalmente restaura a conexão, não os dados perdidos. Se o laptop de um usuário dorme por 30 segundos, ele pode perder eventos e o dashboard pode mostrar totais errados a menos que você desenhe um passo de catch-up (por exemplo: last seen event id ou since timestamp, depois refetch).
Broadcast de alta frequência pode silenciosamente te derrubar. Enviar cada pequena mudança (cada atualização de linha, cada tick de CPU) aumenta carga, tráfego de rede e jitter na UI. Batching e throttling frequentemente fazem o dashboard parecer mais rápido porque as atualizações chegam em blocos limpos.
Fique atento a esses problemas de produção:
Exemplo: um dashboard de suporte mostra contagem ao vivo de tickets. Se você empurra cada mudança de ticket instantaneamente, agentes veem números piscando e às vezes voltando após reconexão. Uma abordagem melhor é enviar atualizações a cada 1–2 segundos e, na reconexão, buscar os totais atuais antes de retomar os eventos.
Imagine um dashboard admin de SaaS que mostra métricas de billing (novas assinaturas, churn, MRR) mais alertas de incidentes (erros de API, backlog de filas). A maioria dos espectadores só observa os números e quer que eles atualizem sem dar refresh. Apenas alguns admins tomam ações.
No começo, comece com o stream mais simples que atende à necessidade. SSE costuma ser suficiente: empurre atualizações de métricas e mensagens de alerta de forma unidirecional do servidor para o navegador. Há menos estado para gerenciar, menos casos de borda e o comportamento de reconexão é previsível. Se uma atualização for perdida, a próxima mensagem pode incluir os totais mais recentes para que a UI se recupere rapidamente.
Alguns meses depois, o uso cresce e o dashboard vira interativo. Agora admins querem filtros ao vivo (mudar janela de tempo, alternar regiões) e talvez colaboração (dois admins confirmando o mesmo alerta e vendo a atualização instantaneamente). É aí que a escolha pode mudar. Mensagens bidirecionais facilitam enviar ações do usuário de volta no mesmo canal e manter o estado compartilhado da UI em sincronia.
Se precisar migrar, faça com segurança em vez de trocar tudo de uma vez:
Antes de colocar um dashboard ao vivo para usuários reais, assuma que a rede será instável e que alguns clientes serão lentos.
Dê a cada atualização um ID único e um timestamp, e escreva sua regra de ordenação. Se duas atualizações chegam fora de ordem, qual vence? Isso importa quando uma reconexão reproduz eventos antigos ou quando múltiplos serviços publicam atualizações.
Reconexão deve ser automática e educada. Use backoff (rápido no começo, depois mais lento) e pare de tentar para sempre quando o usuário fizer logout.
Também decida o que a UI faz quando os dados estão obsoletos. Por exemplo: se não chegar atualização em 30 segundos, desative os gráficos, pause animações e mostre um estado claro de "obsoleto" em vez de exibir números antigos silenciosamente.
Configure limites por usuário (conexões, mensagens por minuto, tamanho de payload) para que uma tempestade de abas não derrube todo mundo.
Monitore memória por conexão e trate clientes lentos. Se um navegador não acompanha, não permita buffers sem limite. Feche a conexão, envie atualizações menores ou mude para snapshots periódicos.
Logue connect, disconnect, reconnect e motivos de erro. Alerta para picos incomuns em conexões abertas, taxa de reconexão e backlog de mensagens.
Tenha um interruptor de emergência simples para desabilitar streaming e voltar para polling ou refresh manual. Quando algo der errado às 2h da manhã, você quer uma opção segura.
Mostre "Última atualização" próximo aos números chave e inclua um botão de refresh manual. Isso reduz tickets de suporte e ajuda usuários a confiar no que veem.
Comece pequeno de propósito. Escolha um stream primeiro (por exemplo, CPU e taxa de requisições, ou só alertas) e escreva o contrato do evento: nome do evento, campos, unidades e frequência de atualização. Um contrato claro evita que UI e backend se distanciem.
Construa um protótipo descartável que foque no comportamento, não no polimento. Faça a UI mostrar três estados: conectando, ao vivo e sincronizando após reconexão. Então force falhas: mate a aba, ative modo avião, reinicie o servidor e observe o que o dashboard faz.
Antes de escalar tráfego, decida como irá recuperar lacunas. Uma abordagem simples é enviar um snapshot na conexão (ou reconexão), então voltar para atualizações ao vivo.
Passos práticos antes de um rollout mais amplo:
Se você estiver se movendo rápido, Koder.ai (koder.ai) pode ajudar a prototipar o fluxo completo rapidamente: uma UI React, um backend Go e o fluxo de dados construídos a partir de um prompt de chat, com exportação do código-fonte e opções de deploy quando estiver pronto.
Uma vez que seu protótipo resista a condições ruins de rede, escalar é principalmente repetir: aumentar capacidade, medir latência e manter o caminho de reconexão simples e confiável.
Use SSE quando o navegador principalmente escuta e o servidor broadcasta. É ideal para métricas, alertas, indicadores de status e painéis de “últimos eventos”, onde ações do usuário são ocasionais e podem ser feitas via requisições HTTP normais.
Escolha WebSockets quando o dashboard também for um painel de controle e o cliente precisar enviar ações frequentes com baixa latência. Se os usuários estiverem constantemente enviando comandos, confirmações, mudanças colaborativas ou outros inputs em tempo real, a comunicação bidirecional costuma ficar mais simples com WebSockets.
SSE é uma resposta HTTP de longa duração onde o servidor empurra eventos para o navegador. WebSockets atualizam a conexão para um protocolo bidirecional separado, permitindo que ambos os lados enviem mensagens a qualquer momento. Para dashboards com foco em leitura, essa flexibilidade bidirecional é muitas vezes um overhead desnecessário.
Adicione um ID de evento (ou número de sequência) a cada atualização e mantenha um caminho claro de “recuperação”. Na reconexão, o cliente deve repassar eventos perdidos (quando possível) ou buscar um snapshot do estado atual, e então retomar as atualizações ao vivo para que a UI volte a ficar correta.
Trate a obsolescência como um estado real da UI, não como uma falha escondida. Mostre algo como “Última atualização” perto dos números principais e, se não chegarem eventos por um tempo, marque a visualização como obsoleta para que os usuários não confiem em dados desatualizados por engano.
Comece mantendo mensagens pequenas e evite enviar cada mudança minúscula. Agregue atualizações frequentes (envie o valor mais recente em vez de cada valor intermediário) e prefira snapshots periódicos para totais. A maior dor de escala costuma ser conexões abertas e clientes lentos, não largura de banda bruta.
Um cliente lento pode fazer buffers do servidor crescerem e consumir memória por conexão. Coloque um limite na fila de dados por cliente, descarte ou regule atualizações quando um cliente não acompanhar, e prefira mensagens de “estado mais recente” em vez de longas filas para manter o sistema estável.
Autentique e autorize cada stream como se fosse uma sessão que precisa expirar. O SSE nos navegadores tende a empurrar para autenticação por cookie porque cabeçalhos customizados não estão disponíveis, enquanto WebSockets geralmente exigem handshake explícito ou uma primeira mensagem de autenticação. Em ambos os casos, aplique permissões de tenant e stream no servidor, não na UI.
Envie eventos pequenos e frequentes pelo canal ao vivo e mantenha trabalho pesado em endpoints HTTP normais. Carregamento inicial da página, consultas históricas, exports e respostas grandes são melhores como requisições regulares; o stream ao vivo deve carregar atualizações leves que mantêm a UI atualizada.
Execute ambos em paralelo por um tempo e espelhe os mesmos eventos em cada canal. Mova uma pequena porcentagem de usuários primeiro, teste reconexões e reinícios de servidor em condições reais e então faça o corte gradual. Manter o caminho antigo brevemente como fallback torna o rollout muito mais seguro.