WebSockets versus Server-Sent Events: wanneer welk protocol wint

WebSockets worden uit reflex gegrepen zodra een feature realtime-gedrag nodig heeft. Meestal is die reflex verkeerd. Server-Sent Events zijn simpeler, goedkoper te draaien, makkelijker te debuggen en passen veel beter bij de broadcast-vormige problemen die het grootste deel uitmaken van de realtime-features die mensen daadwerkelijk releasen: notificaties, live tellers, status-feeds, het streamen van model-output.

De échte regel: kies SSE als de server de bron van waarheid is en clients alleen luisteren. Kies WebSockets als het protocol symmetrisch moet zijn, beide kanten praten, beide kanten doen ertoe, latency is kritiek, en je kunt de operationele belasting absorberen die hoort bij persistente bidirectionele verbindingen.

Wat SSE je oplevert

• Eén richting, één TCP-verbinding, gewoon HTTP/2 eronder. Werkt door elke proxy en CDN die je al draait.
• Auto-reconnect met Last-Event-ID is onderdeel van de spec. De browser doet het retry-rekenwerk; jij schrijft het niet.
• Standaard HTTP-auth, CORS, caching-headers. Niets nieuws te leren voor je edge-laag.
• Goedkoop horizontaal te schalen. Elke verbinding is een long-lived GET; je kunt verkeer afvoeren met dezelfde load balancer die je al gebruikt.

Wanneer WebSockets wél de juiste keuze zijn

Drie patronen forceren WebSockets en niets anders past schoon: collaboratief bewerken waar elke toetsaanslag beide kanten op stroomt, multiplayer of gameplay waar input-latency onder 100ms telt, en elk protocol waar de client hoge-frequentie events terugstuurt naar de server (muispositie, presence, cursor-deling). Voor deze gevallen voegt SSE plus losse POST-requests round-trip overhead toe die je kunt meten.

De kosten zijn operationeel. WebSockets omzeilen je normale HTTP-infrastructuur: speciale CDN-config, sticky load balancing, custom reconnect-logica, en een apart schaalprofiel omdat elke verbinding een worker bezet houdt. Plan daarvoor voordat je naar het protocol grijpt.

De hybride waar we meestal op uitkomen

Op de meeste productiestacks die we releasen, doet SSE de listener-vormige 90% (live dashboards, notificatie-feeds, LLM-token streaming) en handelt een kleine WebSocket-service de symmetrische 10% af (collaboratieve cursors, room presence). De twee mixen is goedkoper dan alles in één protocol persen omdat beide kanten simpel blijven.

De fout is vooraf committen aan WebSockets voor een feature die uiteindelijk eenrichtings blijkt. Terugdraaien is duur: je hebt al betaald voor de sticky load balancer en de reconnect-library. SSE eerst, WebSockets als je ze écht nodig hebt.