Server-Sent Events (SSE) Interview Preparation Guide

Introduction

Server-Sent Events (SSE) is a standard allowing servers to push real-time updates to web clients over a long-lived HTTP connection. In 2026, SSE has become the de facto standard for LLM token streaming, powering the text generation interfaces of major AI platforms. Unlike WebSockets, which provide full-duplex communication, SSE is unidirectional (server-to-client), making it lighter and more efficient for read-heavy streaming tasks. Roles such as Backend Engineer, AI Engineer, and Full-Stack Developer are frequently tested on their ability to implement SSE, manage connection state, and handle re-connection logic. Junior candidates are expected to understand the EventSource API and basic HTTP streaming headers, while senior engineers must demonstrate mastery over connection pooling, proxy behaviors, and the nuances of stateful streaming in distributed systems.

Why It Matters

SSE is critical in 2026 because it provides the lowest-overhead mechanism for streaming LLM responses. When a model generates tokens, SSE allows the server to push each token to the client as it is computed, significantly reducing the perceived latency (Time to First Token). This is vastly more efficient than polling, which incurs the overhead of repeated HTTP handshakes, or WebSockets, which require complex state management for a simple push-only requirement. In high-scale production systems, SSE's reliance on standard HTTP means it integrates seamlessly with existing load balancers, CDNs, and security infrastructure (WAFs) that often struggle with the stateful nature of WebSockets. A strong candidate understands that SSE is not just a 'feature' but a performance optimization strategy. Weak answers often suggest WebSockets for every real-time requirement, failing to account for the resource consumption and operational complexity of maintaining thousands of persistent bidirectional sockets. In an interview, demonstrating knowledge of SSE's automatic reconnection, event IDs, and text/event-stream content type signals a deep understanding of browser networking and efficient resource utilization.

Core Concepts

Architecture Overview

SSE operates over a standard HTTP connection that remains open indefinitely. The server sends a stream of data in a specific format (lines starting with 'data:'). The browser's EventSource object manages the connection, automatically attempting to reconnect if the connection is severed, using the 'Last-Event-ID' header to resume from the last successful message.

Data Flow

The client initiates a GET request. The server holds the request open, periodically writing chunks of data to the response stream. The browser parses these chunks and fires events to the application code.

[Client Browser]
       ↓
  [Load Balancer]
       ↓
[Application Server]
       ↓
[Streaming Generator]
       ↓
[Event Stream Buffer]
       ↓
[HTTP Response Stream]
       ↓
[Client EventSource]

Key Components

Tools & Frameworks

Design Patterns

Generator-based Streaming Implementation Pattern

Using language-native generators (e.g., Python 'yield') to push tokens as they are generated by an LLM.

Trade-offs: Low memory footprint but requires careful exception handling.

Heartbeat Pattern Reliability Pattern

Sending a comment line (e.g., ': heartbeat') every 15-30 seconds to keep the connection alive through proxies.

Trade-offs: Adds minor bandwidth overhead but prevents silent connection timeouts.

Event ID Sequence State Recovery Pattern

Assigning a unique ID to each event and tracking the last seen ID in the client to request missing data.

Trade-offs: Requires persistent storage of events on the server side.

Common Mistakes

Production Considerations

Reliability	Use heartbeat messages to detect dead connections and implement server-side cleanup of stale generators.
Scalability	Horizontal scaling requires a message bus (e.g., Redis) to broadcast events to all instances.
Performance	Disable proxy buffering and use HTTP/2 to avoid connection limits.
Cost	SSE is cost-effective as it reduces the need for frequent polling requests.
Security	Implement authentication via query parameters or headers; ensure CORS is strictly configured.
Monitoring	Track 'active_connections' and 'stream_duration' metrics in Prometheus.

Key Trade-offs

•SSE vs WebSockets (Unidirectional vs Bidirectional)

•HTTP/1.1 vs HTTP/2 (Multiplexing capabilities)

•Stateful vs Stateless (Handling reconnection state)

Scaling Strategies

•Redis Pub/Sub for cross-instance communication

•Load balancer sticky sessions (if required for state)

•Offloading stream management to specialized gateways

Optimisation Tips

•Set 'proxy_buffering off' in Nginx

•Use 'TCP_NODELAY' to reduce latency

•Implement compression (Gzip/Brotli) for text streams

FAQ

What is the main difference between SSE and WebSockets?

SSE is unidirectional (server-to-client) and uses standard HTTP, making it simpler and more firewall-friendly. WebSockets are bidirectional (full-duplex) and require a custom protocol upgrade, which is more complex to scale and manage in infrastructure.

Can I send binary data over SSE?

SSE is designed for text-based data. To send binary data, you must encode it (e.g., Base64) before sending it as a text event. If your application requires high-frequency binary streaming, WebSockets or gRPC are better alternatives.

How do I handle authentication in SSE?

Since EventSource does not support custom headers, you typically pass authentication tokens via query parameters. Ensure these tokens are short-lived and that the connection is served over HTTPS to prevent credential leakage.

Why does my SSE stream stop after 60 seconds?

This is usually caused by a proxy (like Nginx or a load balancer) timing out the idle connection. Ensure your proxy is configured to allow long-lived connections and that you are sending periodic heartbeat comments to keep the connection active.

Does SSE support automatic reconnection?

Yes, the browser's EventSource API automatically attempts to reconnect if the connection is lost. You can control the retry interval by sending a 'retry:' field in the event stream.

Is SSE suitable for real-time chat applications?

SSE is great for the server-to-client push part of a chat app, but you will need a separate POST endpoint for the client to send messages to the server. WebSockets are often preferred for chat to keep everything on one socket.

How do I scale SSE to thousands of users?

You need a message broker like Redis Pub/Sub. When an event occurs, the backend service publishes it to Redis, and each server instance subscribes to the relevant channels to push the message to its connected clients.

What is the 'Last-Event-ID' header used for?

It allows the client to tell the server which event it last received. If the connection drops, the client sends this ID upon reconnection, allowing the server to replay any missed events from its buffer.

Why is SSE better than polling?

Polling requires the client to repeatedly open and close HTTP connections, which is inefficient and introduces latency. SSE keeps a single connection open, allowing the server to push data immediately, resulting in lower latency and reduced server load.

Can I use SSE with HTTP/2?

Yes, SSE works excellently with HTTP/2. HTTP/2 multiplexing allows you to open many SSE streams to the same domain without hitting the browser's connection limit, which is a significant advantage over HTTP/1.1.