What are the tradeoffs between WebSockets, server sent events and polling for real time updates?

Server sent events are the cheapest option when traffic flows server to client only: plain HTTP, automatic reconnect, and they pass through most proxies. WebSockets justify the operational cost when you need bidirectional or high frequency messaging, like chat or collaborative editing. Polling is fine when updates are rare and a few seconds of staleness is acceptable, and it survives every network and load balancer in existence.

The first question is whether the client needs to send anything back over the same channel. Notifications, live counters, a job progress bar, a feed: all one way, and server sent events handle that over ordinary HTTP with built in reconnect and a last event id header so you can resume from where the client dropped. That last part is underrated. WebSockets are the right call for chat, presence, or anything collaborative where clients push frequently and latency matters. The cost is real though: connections are stateful, so scaling past one instance means a pub sub layer like Redis to fan messages across nodes, plus health checks, backpressure and auth on the initial handshake. And polling is not a joke answer. On an admin dashboard I built, updates mattered maybe once a minute, so a poll on window focus with an ETag was about fifteen lines of code, cost nothing to operate, and never woke anyone up at night. I would rather spend the complexity budget where users actually feel it.