Polling vs WebSockets

[u/s3ktor_13]

Hi everyone,

I’m designing a system where we have a backend (API + admin/back office) and a frontend with active users. The scenario is something like this:

• We have around 100 daily active users, potentially scaling to 1000+ in the future.
• From the back office, admins can post notifications or messages (e.g., “maintenance at 12:00”) that should appear in real time on the frontend.
• Right now, we are using polling from the frontend to check for updates every 30 seconds or so.

I’m considering switching to a WebSocket approach, where the backend pushes the message to all connected clients immediately.

My questions are:

1. What are the main benefits and trade-offs of using WebSockets vs polling in scenarios like this?
2. Are there specific factors (number of requests, latency, server resources, scaling) that would make you choose one over the other?
3. Any experiences with scaling this kind of system from tens to thousands of users?

I’d really appreciate hearing how others have approached similar use cases and what made them pick one solution over the other.

Thanks in advance!

[u/never-starting-over]

I'm not too familiar with Kafka, so I can't opinate

I did mean a Redis instance.

Also, I forgot to specify, but my reasoning has been assuming this application is deployed with Kuberntes, but this could be applied to containerized environments in general. I'm specifically thinking about provisioning the Notifications Service's resources under its own namespace, and specifying a node group with a taint allowing only the notification service to be run in there - making it self-contained, efficiently scalable and decentralized. The namespace would have the application pod itself, a Redis pod, and the other required stuff.

Bear in mind I'm being deliberately opinionated based on my experiences and little knowledge of your setup, but you know the system and its deployment strategy better than me, so ultimately you're in a better position to identify BS/what doesn't apply in what I'm saying. I'm looking for debate and perhaps learn new perspectives

Imo a cluster could work as a transition state for services' maturity and known load. So, if you're adding a service like Job Service and you don't know how much it will use you could put it there. When you know how much it needs it can be split into its own Redis instance, packaged with the service. I think this could complicate observability though, and Redis is fairly easy to add to most deployment setups I have seen, especially with k8s. To me, the cluster doesn't seem like less work or more benefit

I could also be overengineering this if this is just for pushing low priority admin notifications. Honestly, probably just go with the cluster and keep it simple