WebSockets versus Server-Sent Events: wanneer welk protocol wint

Zodra een feature realtime-gedrag nodig heeft, grijpen mensen uit reflex naar WebSockets. Meestal is dat de verkeerde reflex. Server-Sent Events zijn simpeler, goedkoper om te draaien, makkelijker te debuggen en passen veel beter bij de broadcast-achtige problemen die het grootste deel uitmaken van de realtime-features die je in de praktijk live zet: notificaties, live tellers, status-feeds, het streamen van model-output.

De echte vuistregel: kies SSE als de server de bron van waarheid is en clients alleen luisteren. Kies WebSockets als het protocol symmetrisch moet zijn, als beide kanten praten en beide kanten ertoe doen, als latency kritiek is, en als je de operationele last aankunt die hoort bij blijvende verbindingen in twee richtingen.

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 zit in de specificatie. De browser doet het retry-rekenwerk; jij hoeft het niet te schrijven.
• Gewone HTTP-auth, CORS, caching-headers. Voor je edge-laag valt er niets nieuws te leren.
• Goedkoop horizontaal te schalen. Elke verbinding is een langlopende GET; je kunt het verkeer afhandelen met dezelfde load balancer die je al gebruikt.

Wanneer WebSockets wél de juiste keuze zijn

Drie patronen dwingen WebSockets af en niets anders past goed: samen bewerken waarbij elke toetsaanslag beide kanten op stroomt, multiplayer of gameplay waar input-latency onder 100ms telt, en elk protocol waarbij de client hoogfrequente events terugstuurt naar de server (muispositie, presence, het delen van cursors). In die gevallen voegt SSE plus losse POST-requests round-trip overhead toe die je kunt meten.

De prijs betaal je operationeel. WebSockets gaan langs je gewone HTTP-infrastructuur heen: aparte CDN-config, sticky load balancing, eigen reconnect-logica, en een apart schaalprofiel omdat elke verbinding een worker bezet houdt. Regel dat van tevoren, voordat je naar het protocol grijpt.

De hybride waar we meestal op uitkomen

Op de meeste productiestacks die we live zetten, doet SSE de luisterende 90% (live dashboards, notificatie-feeds, het streamen van LLM-tokens) en handelt een kleine WebSocket-service de symmetrische 10% af (gedeelde cursors, presence in een room). De twee combineren is goedkoper dan alles in één protocol persen, omdat beide kanten simpel blijven.

De fout is dat je je vooraf vastlegt op WebSockets voor een feature die uiteindelijk maar één richting op gaat. Terugdraaien is duur: je hebt al betaald voor de sticky load balancer en de reconnect-library. Eerst SSE, WebSockets pas als je ze echt nodig hebt.