We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · API Design & Protocols
Server-Sent Events: a one-way channel where the server pushes updates to the client over HTTP. Simpler than WebSockets when you only need server-to-client streaming.
In short
Server-Sent Events (SSE) is a web technology where a server keeps one HTTP connection open and streams a continuous flow of text updates to the browser, one event at a time. It is a one-way push channel, server to client only, built on plain HTTP and exposed in browsers through the EventSource API.
In short
Server-Sent Events (SSE) is a web technology where a server keeps one HTTP connection open and streams a continuous flow of text updates to the browser, one event at a time. It is a one-way push channel, server to client only, built on plain HTTP and exposed in browsers through the EventSource API.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers SSE across a run of lessons, not one page. These 3 alone are about 56 minutes of step-by-step reading, every one with a quiz.
One-way server push over HTTP, real-time updates without the complexity of WebSockets.
The build process that transforms source files into optimized, production-ready assets with hashing, minification, and bundling.
Managing and optimizing CSS, JavaScript, images, and fonts for fast page loads.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Server-Sent Events (SSE)pay once,
yours for life
Server-Sent Events let a server push data to a client whenever it has something new, without the client asking again. The client opens a single HTTP request, the server holds it open, and instead of sending one response and closing, it keeps writing small chunks of text down the same connection.
The browser side is one line of JavaScript: new EventSource('/stream'). That object fires a message event every time the server sends data, plus open and error events. There is no extra protocol to learn and no separate port to manage. It travels over the same HTTP and HTTPS you already use.
The key word is one-way. SSE pushes from server to client only. The client cannot send messages back over the same channel. If the browser needs to talk to the server, it makes a normal separate HTTP request. That limitation is exactly why SSE is simpler than the alternatives.
The server responds with the content type text/event-stream and never closes the body. Each event is plain UTF-8 text in a tiny format: a line starting with data: holds the payload, an optional event: line names the event type, an optional id: line tags the event, and a blank line marks the end of one event. The server can also send retry: to tell the client how long to wait before reconnecting.
Reconnection is built in and automatic. If the connection drops, the browser waits a few seconds and reconnects on its own. It also sends the last id it received in a Last-Event-ID header, so a well-written server can resume from where the client left off instead of replaying everything. You get this resilience for free, which is something WebSockets make you build yourself.
One trap to know about: over HTTP/1.1 a browser allows only about 6 connections per domain, and each open SSE stream eats one of those slots across all tabs. HTTP/2 fixes this by multiplexing many streams over one connection, raising the practical limit to around 100. If you serve SSE at scale, run it over HTTP/2.
Reach for SSE when the data flows mostly in one direction: server to client. Live sports scores, stock tickers, a notification feed, a build or deploy log that streams as it runs, or token-by-token output from an AI model are all natural fits. You get streaming with almost no infrastructure beyond a normal HTTP endpoint.
Use WebSockets instead when you need true two-way, low-latency traffic, like a multiplayer game, a collaborative editor where both sides type, or a chat app with typing indicators. WebSockets are full duplex and can carry binary frames; SSE is text only and one direction.
The trade-off to weigh is simplicity versus capability. SSE works through proxies and firewalls that already understand HTTP, supports automatic reconnect with resume, and needs no special server. The costs are: text only, no client-to-server channel, the per-domain connection limit on HTTP/1.1, and no native support in Internet Explorer (a polyfill covers that if you still care).
ChatGPT and most LLM APIs stream their answers using SSE. When you ask a question, the server does not wait to compute the whole reply. It opens an event stream and sends each token as a separate data: event, which is why you see words appear one at a time. The OpenAI streaming API literally ends the stream with a special data: [DONE] line over text/event-stream.
Picture a stock dashboard. The browser runs const es = new EventSource('/prices'); es.onmessage = e => updateUI(JSON.parse(e.data)). The server pushes a small JSON event each time a price changes. No polling, no WebSocket handshake, and if the user's wifi blips, the browser reconnects and the server resumes from the last event id. That is the whole feature.
OpenAI ChatGPT API
Streams model output token by token as text/event-stream, ending with a data: [DONE] sentinel.
GitHub
Used SSE to push live updates to web pages such as build and CI status without constant polling.
Mercure / Symfony
An open protocol and hub built on SSE for pushing real-time updates to browsers and mobile apps.
Vercel AI SDK
Defaults to SSE to stream chat completions from the server to React components in the browser.
SSE is one-way, server to client only, over plain HTTP, text only, with automatic reconnect built in. WebSockets are two-way (full duplex), support binary data, and use their own upgraded protocol, but you have to handle reconnection yourself. Use SSE for push-only feeds and WebSockets when both sides must send messages.
No. The SSE channel is server to client only. When the client needs to send something, it makes a normal separate HTTP request like a POST. If you need a single connection that carries traffic both ways, use WebSockets instead.
Yes. The browser's EventSource reconnects on its own after a short delay, which the server can tune with a retry: field. If the server tagged events with id: lines, the browser sends a Last-Event-ID header on reconnect so the server can resume from the last delivered event.
Over HTTP/1.1 a browser allows only about 6 connections per domain, shared across all tabs, and each open SSE stream uses one. Over HTTP/2 connections are multiplexed, so the practical limit rises to roughly 100. Serve SSE over HTTP/2 if you expect many concurrent streams.
It responds with Content-Type: text/event-stream and keeps the response body open, writing events as plain text. Each event uses fields like data:, event:, and id:, separated by a blank line.
Asset Pipeline
The build process that transforms source files into optimized, production-ready assets with hashing, minification, and bundling
Static Asset Optimization
Managing and optimizing CSS, JavaScript, images, and fonts for fast page loads
Drift Tests and Sample Size: Why More Rows Can Mean More Alarms
I put three popular drift tests through thousands of comparisons of real shop data, from 100 rows to 50,000. On two groups with no real difference, the KS test rang on 94% of comparisons at 10,000 rows and on every one at 30,000, because each customer appeared up to 31 times and the test counted every repeat as fresh evidence. Counting each customer once, it rang on at most 8% across all four columns, within what luck allows. On small samples PSI and the Wasserstein distance rang by luck instead. Against the training rows, the textbook PSI line of 0.25 was the only one of six lines that stayed quiet on normal nights and still caught 9 of 15 breaks on the first night, and a line set by shuffling whole customers caught a small creep the textbook line missed.
Was the Cheap Model Sure? Choosing Which Questions a Cascade Passes On
A cascade lets a cheap model answer first and passes some questions to a strong model. Everything depends on the clue that picks which ones. On 175 maths problems with known answers, the cheap model said it was 100 out of 100 sure on almost every answer, so asking how sure did exactly as well as random. Asking it three times beat random clearly, but mostly by spotting hard questions, a free rule on the question did about as well, and in tokens it cost as much as the strong model alone.
The Full ML Platform: Assembling Every Piece Into One Golden Path
How packaging, serving, pipelines, feature stores, registries, monitoring, and scaling assemble into one self-service internal ML platform
WebSocket
A protocol for full-duplex communication over a single TCP connection. Unlike HTTP, the server can push data to the client without being asked.
HTTP
The protocol powering the web. A request-response model where clients ask for resources and servers respond. Stateless by design.
Rate Limiting
Controlling how many requests a client can make in a given time window. Protects your API from abuse and ensures fair usage.
GraphQL
A query language for APIs where the client specifies exactly what data it needs. No over-fetching, no under-fetching. One endpoint to rule them all.
gRPC
A high-performance RPC framework by Google using Protocol Buffers and HTTP/2. Much faster than REST for service-to-service communication.
Protocol Buffers
Google's language-neutral, binary serialization format. Smaller and faster than JSON. Defines schemas in .proto files that generate typed code for any language.
This page explains the idea. The "Server-Sent Events (SSE)" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Server-Sent Events (SSE) lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about SSE in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
