Topic 6.9
SSE (Server-Sent Events)
In one line
One-way server→client push over a single long-lived HTTP connection — the cheap realtime win.
Think of it like this
A stock ticker screen at a trading office. It only pushes updates one-way (numbers scrolling by) — you never talk back to the screen. That's simpler and cheaper than a two-way phone call (WebSocket) when you only need updates flowing one direction.
Key ideas
- 01
EventSource API; server sends text/event-stream lines indefinitely.
- 02
One-directional (server → client) — built-in auto-reconnect with last-event-id resume.
- 03
Cost: far cheaper than WebSockets (no special LB stickiness beyond persistence, plain HTTP)
- 04
Perfect for: notifications, stock ticks, feed updates, progress bars.
- 05
Not for: client→server messages (use normal POST) or bidi (use WebSocket).
- 06
Interview: 'for one-way push choose SSE over WebSocket' — a sentence that separates people.
Java / Spring map
- →
Spring: SseEmitter (MVC) or WebFlux ServerSentEvent + Flux.
Explain without notes
Give one product WHERE SSE wins over WebSocket and one where it fails.
Practice
Design a notification stream: SSE endpoint, reconnect with last-event-id, and event shaping.
Trade-offs
- ↔
Single connection per client means the server must fan messages to many live connections — same memory math as WebSocket.
Completion checklist
I know exactly when SSE is the right tool over WebSocket.