SSE, em português claro
Pense no SSE como um “canal de notícias” unidirecional: o cliente abre uma conexão HTTP e o servidor vai enviando mensagens conforme surgem eventos.
O ponto prático: você reduz a necessidade de ficar perguntando “tem novidade?” a cada X segundos (polling) e passa a receber “empurrado” (push) — mas só do servidor para o cliente.
SSE vs Webhook vs WebSocket (diferença que evita arquitetura torta)
Na automação, esses três termos aparecem como se fossem a mesma coisa. Não são. A escolha errada vira gambiarra: polling demais, timeout, ou dependência desnecessária de estado.
| Tecnologia | Melhor para | Como funciona | Pegadinhas comuns |
|---|---|---|---|
| SSE | Atualizações ao vivo (status/logs/progresso) para um cliente conectado | Cliente abre conexão HTTP e recebe eventos contínuos | Nem toda infra gosta de conexões longas; precisa reconexão/retomada |
| Webhook | Notificar um evento pontual para um endpoint seu (ex.: pagamento aprovado) | Sistema A chama seu endpoint quando algo acontece | Requer endpoint público, assinatura/HMAC, idempotência e retry bem feitos |
| WebSocket | Interação bidirecional em tempo real (chat, colaboração, controle) | Conexão persistente 2 vias (cliente ↔ servidor) | Mais complexo de operar; autenticação e escalabilidade pedem cuidado |
| Polling | Quando não existe push (nem webhook, nem SSE) | Seu sistema consulta periodicamente o outro | Custo e latência variáveis; risco de rate limit |
Quando SSE faz sentido em automações (casos bem pé no chão)
SSE brilha quando você precisa de “telemetria humana”: alguém olhando uma tela e querendo entender o que está acontecendo agora, sem ficar recarregando página ou apertando F5.
Quando NÃO usar SSE (e o que usar no lugar)
SSE não é a melhor escolha para “entrega garantida” entre sistemas. Para integrações críticas (pedido, pagamento, nota), normalmente webhook + idempotência + fila/retry é o caminho mais seguro.
Também não é o ideal para conversa bidirecional (o cliente mandar mensagens contínuas pro servidor). Aí WebSocket costuma ser mais apropriado.
Checklist rápido para operar SSE sem dor
SSE parece simples — e é — mas costuma quebrar por detalhes de operação. Se você acertar os pontos abaixo, a chance de susto cai bastante.
Perguntas frequentes
SSE substitui webhook em automação?
SSE funciona bem atrás de proxy e CDN?
SSE é melhor que polling?
Dá para usar SSE com n8n?
Termos relacionados
Webhook
Entenda o que é webhook, como funciona na prática e como usar no n8n e Make para criar automações em tempo real sem precisar saber programar.
Ler →
Webhook vs API: Qual a Diferença e Exemplos Práticos na Automação
Entenda de forma clara a diferença entre webhook e API, com exemplos do dia a dia na automação de processos. Veja quando faz sentido usar cada um.
Ler →
Webhook no n8n: como receber, tratar e responder HTTP (sem gambiarra)
Aprenda a criar um webhook no n8n, validar assinatura, tratar payload, evitar duplicidade e responder HTTP 200/400/500 com padrão de produção.
Ler →
Webhook ou polling em automações: como escolher (sem perder eventos e sem estourar limites)
Guia direto para decidir entre webhook e polling: latência, confiabilidade, custo por execução, rate limit e como evitar duplicidades. Inclui tabela e checklist prático.
Ler →