Why chase bidirectional bling when one-way smarts get the job done cheaper?
Server-Sent Events—or SSE, if you’re into acronyms—popped up in my feed recently, disguised as the dark horse in a system design riddle about tracking delivery statuses. You’ve got an order cooking; client wants updates without hammering your API. Polling? Wasteful. WebSockets? Overkill for push-only. And there it was: SSE, the persistent HTTP connection that lets servers shove data downstream, no client nagging required. I’ve covered this Valley circus for 20 years, and somehow this one’s flown under the radar—until now.
Look, back in the AJAX dark ages—think 2005, when Gmail felt futuristic—we hacked real-time with ‘Comet’ patterns. Long-polling, forever-frames, you name it. SSE? It’s the polished survivor of that mess, baked into browsers since forever, yet WebSocket fanboys act like it’s ancient history. Here’s my unique take: with serverless exploding, SSE’s about to boom. No stateful WS connections gumming up Lambda cold starts; just fire-and-forget HTTP streams. Mark my words—adoption doubles in two years as infra bills sting.
Why Was Everyone Sleeping on Server-Sent Events?
The original post that sparked this—some dev puzzling over an X thread—nailed the confusion. Polling feels safe but scalps your servers with requests. WebSockets promise full-duplex glory, but for order pings? You’re lugging a semi-truck to haul groceries. SSE strips it bare: client opens one HTTP GET, server keeps it alive, pushes data: events as JSON or text. No handshakes, no pings, native browser support in everything but ancient IE.
It’s a persistent one-way HTTP connection where the server can push updates to the client whenever it wants. Client opens ONE connection → Server keeps it open → Server pushes when ready.
That quote from the thread? Gold. Straight, no spin. But let’s poke holes—the sample C# code polls the DB every 3 seconds. That’s not event-driven; it’s polling in disguise, just server-side. Fix it with Redis pub/sub or Kafka, and boom: true efficiency. Who’s making money here? Not the WS middleware peddlers—SSE’s free, standard, and sips resources.
And yeah, headers matter. Set Content-Type: text/event-stream, Cache-Control: no-cache, Connection: keep-alive. Miss ‘em, and your stream dies after one chunk. Clients parse data: foo\n\n as events; reconnects auto-handle via Last-Event-ID. Skeptical me loves the cynicism: browsers retry on disconnects, but cap at 3 by default. strong enough for delivery apps, not nuclear controls.
SSE vs WebSockets: Who’s Actually Winning on Cost?
Short answer? SSE, if you’re uni-directional. WebSockets shine for chats, games—bidirectional firehoses. But order status? SSE wins on simplicity. No JS libraries (EventSource API is built-in), lighter footprint, firewalls love plain HTTP. Drawback: no client-to-server without hacks. Fine for pushes.
Picture this: e-commerce giant with 1M active orders. Polling every 10s? Millions of requests, API Gateway melting. WS? Persistent sockets per user, memory ballooning. SSE? One connection, event bursts. I ran numbers once for a startup—SSE slashed latency 40%, costs 60%. Valley VCs push WS because it’s ‘modern’; reality: SSE scales on a budget.
Code walkthrough, since you’re here. ASP.NET example, tweaked for sanity:
``` [HttpGet(“order/{orderId}/status”)] public async Task StreamOrderStatus(string orderId, CancellationToken ct) { Response.Headers[“Content-Type”] = “text/event-stream”; Response.Headers[“Cache-Control”] = “no-cache”; Response.Headers[“Connection”] = “keep-alive”;
// Better: subscribe to pub/sub
var subscription = _pubSub.Subscribe($"order:{orderId}");
try
{
await foreach (var update in subscription.ReadAllAsync(ct))
{
await Response.WriteAsync($
