It's a bit more complicated than that. WebSocket and Server-Sent events cannot be really used interchangeably. Each addresses a different situation. If your backend architecture is event-driven, you'll have to use WebSocket (or MQTT or long/short polling). It's because in an event driven arch, a request to the backend will normally trigger a chain of asynchronous calls to multiple microservices. Once an incoming request leaves the boundary of the first microservice it will be forgotten and left to the broker, and server-sent event solution is almost impractical in this situation (the first microservice that handles the HTTP request should wait for an async response from the message broker then it should match the original request to the reply, etc.... this is not practical. Using websockets simplifies this process). If your backend (a) is not event driven (b) and handles the requests synchronously without using a broker, (c) but it needs to stream back intermediate responses/updates to the client, then server-sent event is a better solution than websocket and polling. In simple words, if you need to decouple invocation from execution (event-driven architecture) in the back-end, then go for Webscoket in the front-end, otherwise if you need to stream back intermediate updates in a request-reply fashion, go for server-sent events.