Quais são os tradeoffs entre WebSockets, server sent events e polling para atualizações em tempo real?

Server sent events são a opção mais barata quando o tráfego flui só do servidor para o cliente: HTTP puro, reconexão automática, e eles passam pela maioria dos proxies. Os WebSockets justificam o custo operacional quando você precisa de mensagens bidirecionais ou de alta frequência, como chat ou edição colaborativa. Polling serve bem quando as atualizações são raras e alguns segundos de desatualização são aceitáveis, e ele sobrevive a toda rede e todo load balancer que existe.

A primeira pergunta é se o cliente precisa mandar alguma coisa de volta pelo mesmo canal. Notificações, contadores ao vivo, uma barra de progresso de job, um feed: tudo de mão única, e server sent events dão conta disso sobre HTTP comum com reconexão embutida e um header de last event id para você retomar de onde o cliente caiu. Essa última parte é subestimada. WebSockets são a escolha certa para chat, presença, ou qualquer coisa colaborativa em que os clientes empurram com frequência e a latência importa. O custo é real, porém: as conexões têm estado, então escalar além de uma instância significa uma camada de pub sub como o Redis para distribuir mensagens entre nós, mais health checks, contrapressão e autenticação no handshake inicial. E polling não é resposta de piada. Em um painel administrativo que eu construí, as atualizações importavam talvez uma vez por minuto, então um poll no foco da janela com um ETag foram umas quinze linhas de código, não custaram nada para operar, e nunca acordaram ninguém de madrugada. Eu prefiro gastar o orçamento de complexidade onde os usuários de fato sentem.