ASP.NET Core Minimal APIs support Server-Sent Events, which makes SSE a first-class option in .NET rather than something you hand-roll. That's a good excuse to write down how I'd actually choose between SSE, WebSockets, and plain polling — because the decision gets made badly more often than it gets made well.
In claims processing there are several places a user is waiting on something that takes an unpredictable amount of time: a submission being adjudicated, a pre-authorization coming back, a batch finishing. Every one of those is a push-channel decision, and reaching for WebSockets by reflex is the most common mistake.
Start With the Direction of the Data
This single question resolves most cases.
Server to client only? SSE. Status updates, progress, notifications, live dashboards, a feed of events. The client subscribes and receives. That's the entire shape of the problem, and SSE is built exactly for it.
Genuinely bidirectional, low latency, high frequency? WebSockets. Collaborative editing, chat, live multiplayer, anything where the client is sending as constantly as it's receiving.
The trap is that WebSockets can do the first case, so people use them for it. You then own a second protocol, a different upgrade path, a connection lifecycle to manage, and infrastructure that has to be configured to allow it — in exchange for capability you don't use.
Why SSE Is Underrated
SSE is just HTTP. That sentence is doing a lot of work:
- Proxies, load balancers, and corporate firewalls already handle it. Every place a WebSocket upgrade gets blocked or mangled, SSE goes through, because it's an ordinary long-lived response.
- Reconnection is built in. Browsers reconnect automatically, and with
Last-Event-IDthe client tells you where it left off, so you can resume rather than resend. Implementing that properly over raw WebSockets is work you'd have to do yourself. - Your existing middleware applies. Auth, logging, rate limiting, tracing — all the HTTP machinery you already have works unchanged.
- It's trivially debuggable.
curlthe endpoint and watch events arrive. Try that with a WebSocket.
In .NET, the Minimal API surface maps onto IAsyncEnumerable<T>, which is a natural fit: a background service produces events, the endpoint streams them, the framework handles the wire format.
What to Watch For
SSE isn't free of sharp edges.
Connection count. Each subscriber holds a connection open. That's fine at hundreds, needs thought at tens of thousands. Know roughly where your ceiling is before you find it.
Buffering proxies. A proxy that buffers responses will happily hold your events until the buffer fills, turning real-time into batch. This is the single most common "SSE doesn't work" report and it's almost always a proxy configuration, not the code.
Scaling out. With multiple instances, the instance holding the connection may not be the one that produced the event. You need a backplane — a message bus the producing instance publishes to and every instance subscribes to. This is true of WebSockets too, and it's the part people forget when they estimate the work.
Long-lived connections and deploys. Every deployment drops every connection. With automatic reconnection that's survivable, but your resume logic needs to actually work, and that's worth testing deliberately rather than discovering during a rollout.
When Polling Is Right
I want to defend polling, because it gets dismissed too quickly.
If updates are infrequent, latency tolerance is measured in seconds, and the client population is large, polling with a sensible interval and conditional requests is simpler, cheaper, and more robust than any push mechanism. No held connections, no backplane, no reconnection logic, no deploy interaction. It scales horizontally with zero coordination.
"Real-time" is a requirement that should be justified, not assumed. A status that changes twice an hour does not need a persistent connection. A claim that takes thirty seconds to adjudicate does not need sub-second push — the user is looking at a spinner either way.
The honest question is: what does the user do differently if they find out two seconds sooner? Often nothing.
The Decision, Compressed
Server-to-client only, and updates matter within seconds → SSE. Truly bidirectional and chatty → WebSockets. Infrequent updates, large client count, or you want the simplest thing that works → polling.
Pick the least machinery that satisfies the requirement. In my experience that's SSE more often than teams expect, and polling more often than they'd like to admit.
