Quando você usaria WebSockets, SSE ou long-polling em vez de HTTP simples?

Question

IT Interview Practice · Accepted Answer

O HTTP simples é **request/response**: o cliente pede, o servidor responde, fim. Isso encaixa mal em recursos **real-time** (chat, dashboards ao vivo, notificações, edição colaborativa) onde o *servidor* precisa empurrar dados sempre que tem algo novo. As opções são formas de contornar o modelo iniciado pelo cliente do HTTP, ao longo de um espectro de complexidade:

```text
Long-polling   client ──req──▶ server ...holds... ──resp──▶ then immediately re-asks
               (near-real-time over plain HTTP; one message per held request)

SSE            client ──req──▶ server ═══stream of events═══▶ (one-way, server→client)
               (HTTP-based, text, auto-reconnect; NO client→server on same channel)

WebSocket      client ──handshake──▶ server ══full-duplex, both directions══▶
               (persistent TCP; low overhead; binary or text; you build the rest)
```

O **long-polling** é o fallback que funciona em todo lugar: o cliente faz uma requisição normal que o servidor mantém aberta até ter dados, e então o cliente imediatamente refaz a requisição. Ele aproxima o push sobre HTTP simples mas desperdiça um ciclo de requisição por mensagem e adiciona latência.

O **SSE (Server-Sent Events)** é um stream **unidirecional** (servidor → cliente) leve e padronizado sobre uma única resposta HTTP de longa duração. É ideal quando apenas o servidor empurra — feeds ao vivo, notificações, progresso, streaming de tokens de LLM. É simples, roda sobre HTTP/2 normal (sem infraestrutura especial) e reconecta automaticamente. O limite: é unidirecional e apenas texto.

Os **WebSockets** promovem uma única conexão HTTP num canal TCP persistente e **full-duplex** onde ambos os lados enviam a qualquer momento com overhead mínimo por mensagem. Use para interação genuinamente bidirecional e de baixa latência: chat, jogos multiplayer, editores colaborativos, trading. O custo é operacional — é uma conexão stateful para a qual proxies, load balancers e autoscalers precisam ser configurados, e você mesmo precisa construir reconexão, heartbeats e backpressure.

**Regra de bolso:** use HTTP simples por padrão; use **SSE** para streaming servidor→cliente; recorra a **WebSockets** apenas quando você realmente precisar de real-time bidirecional; mantenha **long-polling** como o fallback universal.

## Por que isso importa

Escolher um transporte real-time é uma clássica decisão de design sênior onde a resposta ingênua ("use WebSockets para tudo") geralmente está errada. Os entrevistadores querem ver que você combina a ferramenta com o *padrão de comunicação* — unidirecional vs bidirecional, necessidades de latência, volume de mensagens — e que você pondera o **custo operacional** de conexões stateful e de longa duração: sticky sessions, scaling, timeouts de proxy e lógica de reconexão. Reconhecer que o SSE muitas vezes cobre "o servidor empurra atualizações" de forma mais simples que WebSockets, e que o long-polling continua sendo um fallback robusto, sinaliza experiência real de produção em vez de recorrer à opção mais chamativa.

Por que isso importa

Perguntas relacionadas