WebSocket vs SSE vs long polling: decision framework for real-time features

when designing real-time features, the choice between websockets, sse, and long polling feels like a constant debate. at work, we're often dealing with systems that need to push updates to hundreds of thousands of concurrent users, primarily for mobile web clients. things like notifying a user their booking status changed, or a host received a new message. we're not typically doing bi-directional chat, mostly server-to-client notifications. websocket is powerful for full-duplex, but the overhead of maintaining those connections at scale, plus proxy compatibility issues (especially corporate firewalls that drop them), can be a headache. sse feels simpler, more HTTP-friendly, and reconnects automatically. but then you hit connection limits on the server, and mobile clients can sometimes struggle with keeping sse connections alive in the background. long polling is kind of the old reliable, but it's resource-intensive on the server side and introduces inherent latency for updates. what's your framework for choosing? are there specific scenarios where sse shines over websockets, or vice versa, especially when you need to support 100k+ users and navigate enterprise network restrictions?