One-Way Server Push - Server-Sent Events (SSE) | OneNoughtOne

0/319

System Design (HLD)Server-Sent Events (SSE)

Server-Sent Events (SSE)

LevelIntermediate

Duration60 mins

TopicServer-Sent Events (SSE)

1 / 5

One-Way Server Push

The Power of Server Push

In the traditional HTTP request-response model, clients are constantly asking: "Do you have anything new for me?" This polling approach is inefficient—wasting bandwidth when nothing has changed and introducing latency when updates do occur. But what if the server could simply tell the client when something happens?

Server-Sent Events (SSE) represent a paradigm shift in client-server communication. Instead of clients repeatedly asking for updates, servers push data to clients as soon as it becomes available. This one-way streaming model is elegantly simple yet remarkably powerful, forming the backbone of live feeds, real-time dashboards, and notification systems across the modern web.

What You Will Learn

By the end of this page, you will understand the fundamental architecture of one-way server push, how SSE leverages HTTP to establish persistent streaming connections, the protocol mechanics that enable efficient real-time updates, and why this deceptively simple technology solves complex distributed systems challenges with elegance.

The Polling Problem

To appreciate the elegance of server push, we must first understand the limitations of the request-response model and the various attempts to work around them.

Traditional Polling (Short Polling)

The naive approach to real-time updates involves clients periodically requesting data:

Client → Server: GET /updates (every 5 seconds)
Server → Client: 200 OK, { updates: [] }

Client → Server: GET /updates (5 seconds later)
Server → Client: 200 OK, { updates: [] }

// ...99 empty responses later...

Client → Server: GET /updates 
Server → Client: 200 OK, { updates: [{ message: "Finally!" }] }

The problems with this approach are substantial:

Short Polling Limitations

•Wasted Bandwidth — Most requests return no new data, yet each request incurs full HTTP overhead (headers, TLS handshake for new connections, etc.)
•Latency Trade-off — Short intervals waste resources; long intervals delay updates. There's no optimal frequency.
•Server Load — Thousands of clients polling simultaneously creates significant server overhead, even when nothing has changed.
•Battery Drain — Mobile devices suffer from constant network activity, preventing radio from entering low-power state.
•Scalability Ceiling — At scale, polling traffic dominates actual useful traffic, limiting system capacity.

Long Polling: A Step Forward

Long polling attempts to address the latency issue by holding the request open until data is available:

Client → Server: GET /updates
Server: (holds connection open...)
Server: (waits for event...)
Server → Client: 200 OK, { updates: [{ message: "New data!" }] }
Client → Server: GET /updates (immediately reconnects)

This reduces latency to near-zero when events occur, but introduces its own problems:

Long Polling Challenges

•Connection Churn — Each response closes the connection, requiring a new request. High-frequency updates mean constant reconnection overhead.
•Proxy and Load Balancer Issues — Many proxies timeout idle connections, requiring careful timeout tuning.
•Out-of-Order Delivery — Multiple long-poll requests can complete out of order, complicating state management.
•Header Redundancy — Full headers are re-sent with every request/response cycle.
•Sticky Sessions Complexity — Maintaining consistent routing across reconnects is challenging in distributed environments.

The Fundamental Insight

Both polling approaches fight against HTTP's fundamental design as a request-response protocol. Server-Sent Events embrace HTTP's strengths (ubiquity, firewall-friendliness, simple caching semantics) while introducing a streaming capability that eliminates the need for repeated requests.

SSE Architecture: The Push Model

Server-Sent Events provide a standardized, browser-native way to receive a continuous stream of updates from a server over HTTP. Unlike bidirectional WebSockets, SSE focuses on a single, optimized use case: server-to-client streaming.

The Core Architecture

SSE establishes a unidirectional channel from server to client:

Converting Mermaid diagram...

How SSE Works Under the Hood

Connection Establishment: The client creates an EventSource object pointing to an SSE endpoint. This initiates a standard HTTP GET request.
Content-Type Negotiation: The server responds with Content-Type: text/event-stream, signaling that the response will be a continuous stream rather than a single response body.
Keep-Alive: The connection remains open. The server sends events whenever they occur, formatted according to the SSE protocol.
Automatic Parsing: The browser's EventSource API automatically parses incoming events and dispatches them to JavaScript handlers.
Automatic Reconnection: If the connection drops, EventSource automatically attempts to reconnect, resuming from the last received event.

SSE Protocol Example

HTTP Stream

HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache
Connection: keep-alive
 
: This is a comment (lines starting with colon are ignored)
 
data: Simple message with just data field
 
event: userJoined
data: {"userId": "123", "name": "Alice"}
 
id: 12345
event: stockUpdate  
data: {"symbol": "AAPL", "price": 178.50}
data: {"change": "+1.2%"}
retry: 5000
 
id: 12346
event: stockUpdate
data: {"symbol": "GOOG", "price": 141.20}

Protocol Simplicity

The SSE protocol is intentionally minimal. Events are plain text, fields are separated by newlines, and messages are separated by blank lines. This simplicity means you can debug SSE with curl, test with any HTTP client, and implement servers in any language with minimal overhead.

The SSE Protocol in Depth

The Server-Sent Events protocol defines a simple text-based format for streaming events. Understanding this format is crucial for implementing robust SSE systems.

Message Fields

Each event can contain the following fields:

SSE Message Fields
Field	Purpose	Behavior
data:	Event payload (required)	Multiple data lines are concatenated with newlines. Triggers dispatch when message completes.
event:	Event type name	Determines which event listener receives the message. Defaults to 'message' if omitted.
id:	Event identifier	Sets lastEventId. Sent to server on reconnection via Last-Event-ID header.
retry:	Reconnection delay (ms)	Tells client how long to wait before reconnecting after disconnect.
:	Comment	Ignored by client. Useful for keep-alive pings to prevent connection timeout.

Message Parsing Rules

The SSE parser follows precise rules that enable reliable streaming:

•Line Parsing: Stream is parsed line-by-line. Lines ending in LF, CR, or CRLF are recognized.
•Field Extraction: Each line is split at the first colon. The text before is the field name; after (minus optional leading space) is the value.
•Data Accumulation: Multiple data: lines within an event are joined with characters.
•Event Dispatch: A blank line signals the end of an event. The accumulated data is dispatched to handlers.
•Buffer Reset: After dispatch, the event data buffer is cleared for the next message.

Multi-Line Data Example

event: notification
id: msg-001
data: {
data:   "type": "alert",
data:   "title": "System Update",
data:   "body": "Maintenance scheduled for 3:00 AM UTC",
data:   "priority": "high"
data: }
 
event: heartbeat
data: ping

JSON Parsing Consideration

While data fields can span multiple lines for readability in examples, production systems typically send each JSON object on a single data line to simplify parsing and avoid newline handling complexities. The multi-line format is more useful for human-readable messages or when streaming very large objects.

Client-Side Implementation

The browser's EventSource API provides a robust, production-ready interface for consuming SSE streams. Understanding its features enables building reliable real-time applications.

Basic Usage

eventsource-basics.js
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
// Create connection to SSE endpoint
const eventSource = new EventSource('/api/events');
 
// Handle generic messages (event: field omitted or set to 'message')
eventSource.onmessage = (event) => {
    const data = JSON.parse(event.data);
    console.log('Message received:', data);
    console.log('Event ID:', event.lastEventId);
};
 
// Handle specific event types
eventSource.addEventListener('notification', (event) => {
    const notification = JSON.parse(event.data);
    showNotification(notification.title, notification.body);
});
 
eventSource.addEventListener('stockUpdate', (event) => {
    const update = JSON.parse(event.data);
    updateStockTicker(update.symbol, update.price);
});
 
// Connection lifecycle events
eventSource.onopen = () => {
    console.log('SSE connection established');
    updateConnectionStatus('connected');
};
 
eventSource.onerror = (error) => {
    if (eventSource.readyState === EventSource.CONNECTING) {
        console.log('Reconnecting to SSE...');
    } else if (eventSource.readyState === EventSource.CLOSED) {
        console.error('SSE connection failed permanently');
        handleConnectionFailure();
    }
};
 
// Clean up when no longer needed
function cleanup() {
    eventSource.close();
    console.log('SSE connection closed');
}

EventSource Ready States

The readyState property indicates the connection status:

EventSource Connection States
State	Value	Description
CONNECTING	0	Connection is being established or reconnection is in progress.
OPEN	1	Connection is active and receiving events.
CLOSED	2	Connection is closed and will not reconnect automatically.

Authentication Consideration

EventSource doesn't support custom headers, which complicates token-based authentication. Common workarounds include: (1) passing tokens as query parameters, (2) using cookies for authentication, or (3) establishing auth via a separate endpoint before SSE connection. For complex auth requirements, consider using a polyfill library like 'event-source-polyfill' that supports custom headers.

Server-Side Implementation

Implementing an SSE server requires understanding HTTP streaming, connection management, and event formatting. Let's examine implementations across popular frameworks.

SSE Server Implementations

const express = require('express');
const app = express();
 
// Store connected clients
const clients = new Map();
let clientIdCounter = 0;
 
// SSE endpoint
app.get('/api/events', (req, res) => {
    // Set SSE headers
    res.setHeader('Content-Type', 'text/event-stream');
    res.setHeader('Cache-Control', 'no-cache');
    res.setHeader('Connection', 'keep-alive');
    res.setHeader('X-Accel-Buffering', 'no'); // Disable nginx buffering
    
    // Prevent request timeout
    req.setTimeout(0);
    
    // Send initial comment to establish connection
    res.write(': connected
 
');
    
    // Register client
    const clientId = ++clientIdCounter;
    clients.set(clientId, res);
    console.log(`Client ${clientId} connected. Total: ${clients.size}`);
    
    // Handle client disconnect
    req.on('close', () => {
        clients.delete(clientId);
        console.log(`Client ${clientId} disconnected. Total: ${clients.size}`);
    });
});
 
// Broadcast event to all clients
function broadcast(event, data, id = null) {
    const message = formatSSE(event, data, id);
    for (const [clientId, res] of clients) {
        res.write(message);
    }
}
 
// Format SSE message
function formatSSE(event, data, id = null) {
    let message = '';
    if (id) message += `id: ${id}
`;
    if (event) message += `event: ${event}
`;
    message += `data: ${JSON.stringify(data)}
 
`;
    return message;
}
 
// Send heartbeat every 30 seconds
setInterval(() => {
    for (const [clientId, res] of clients) {
        res.write(': heartbeat
 
');
    }
}, 30000);
 
// Example: broadcast stock updates
setInterval(() => {
    broadcast('stockUpdate', {
        symbol: 'AAPL',
        price: (170 + Math.random() * 10).toFixed(2),
        timestamp: new Date().toISOString()
    });
}, 5000);
 
app.listen(3000);

Critical: Response Buffering

Many web servers and reverse proxies buffer responses before sending them to clients. This defeats SSE's real-time nature. Always disable buffering with appropriate headers (X-Accel-Buffering: no for Nginx) and ensure your application framework flushes responses immediately.

Why One-Way Is Often Enough

At first glance, SSE's one-way nature might seem like a limitation. After all, WebSockets offer bidirectional communication. However, for many use cases, the one-way model is not just sufficient—it's preferable.

The Hybrid Architecture Pattern

In practice, most real-time applications combine SSE for server push with regular HTTP for client-to-server communication:

Converting Mermaid diagram...

This pattern offers significant advantages over pure WebSocket implementations:

Benefits of SSE + HTTP

•Familiar Request-Response — Client actions use standard REST/HTTP, with proper status codes, caching, and error handling.
•Load Balancer Friendly — SSE works through standard HTTP infrastructure without special configuration.
•Connection Efficiency — One persistent SSE connection handles all server updates; HTTP/2 multiplexes client requests.
•Simple Authentication — Client requests use standard auth headers; only SSE needs special handling.
•Automatic Retry Logic — EventSource handles reconnection automatically, with exponential backoff.

Ideal Use Cases

•Live Feeds — News, social media, sports scores—where updates flow in one direction.
•Dashboards — Real-time metrics, monitoring UIs, admin panels.
•Notifications — System alerts, user mentions, activity updates.
•Progress Tracking — Long-running jobs, file processing, build pipelines.
•Stock Tickers — Financial data where clients only consume, never produce.

Design Principle

Choose the simplest technology that solves your problem. If your real-time needs are server-to-client only, SSE's simplicity, native browser support, and HTTP compatibility make it the right choice. Reserve WebSockets for truly bidirectional scenarios like collaborative editing or multiplayer games.

Summary: One-Way Server Push

We've established the foundational concepts of Server-Sent Events and the one-way push model. Let's consolidate the key takeaways:

Key Takeaways

•Polling is inefficient — Both short and long polling waste resources and introduce latency. Server push eliminates these problems.
•SSE uses standard HTTP — No special protocols or ports. Works through firewalls, proxies, and existing infrastructure.
•The protocol is simple — Text-based format with data, event, id, and retry fields. Easy to debug and implement.
•EventSource is built-in — Browsers provide native, production-ready SSE client with automatic reconnection.
•One-way is often optimal — Combined with HTTP for client-to-server communication, SSE covers most real-time scenarios.
•Hybrid architecture wins — SSE for push + REST for actions gives you the best of both worlds.

What's Next:

Now that we understand the fundamentals of SSE and one-way server push, we'll examine how SSE compares to WebSockets in detail. Understanding the trade-offs between these technologies is crucial for making the right architectural decisions.

Page Complete

You now understand the architecture and mechanics of one-way server push with SSE. You can implement basic SSE servers and clients, and you understand when this pattern is preferable to bidirectional alternatives. Next, we'll explore SSE vs WebSocket trade-offs in detail.

System Design (HLD)Server-Sent Events (SSE)

Server-Sent Events (SSE)

LevelIntermediate

Duration60 mins

TopicServer-Sent Events (SSE)

1 / 5

One-Way Server Push

The Power of Server Push

What You Will Learn

The Polling Problem

To appreciate the elegance of server push, we must first understand the limitations of the request-response model and the various attempts to work around them.

Traditional Polling (Short Polling)

The naive approach to real-time updates involves clients periodically requesting data:

Client → Server: GET /updates (every 5 seconds)
Server → Client: 200 OK, { updates: [] }

Client → Server: GET /updates (5 seconds later)
Server → Client: 200 OK, { updates: [] }

// ...99 empty responses later...

Client → Server: GET /updates 
Server → Client: 200 OK, { updates: [{ message: "Finally!" }] }

The problems with this approach are substantial:

Short Polling Limitations

•Wasted Bandwidth — Most requests return no new data, yet each request incurs full HTTP overhead (headers, TLS handshake for new connections, etc.)
•Latency Trade-off — Short intervals waste resources; long intervals delay updates. There's no optimal frequency.
•Server Load — Thousands of clients polling simultaneously creates significant server overhead, even when nothing has changed.
•Battery Drain — Mobile devices suffer from constant network activity, preventing radio from entering low-power state.
•Scalability Ceiling — At scale, polling traffic dominates actual useful traffic, limiting system capacity.

Long Polling: A Step Forward

Long polling attempts to address the latency issue by holding the request open until data is available:

Client → Server: GET /updates
Server: (holds connection open...)
Server: (waits for event...)
Server → Client: 200 OK, { updates: [{ message: "New data!" }] }
Client → Server: GET /updates (immediately reconnects)

This reduces latency to near-zero when events occur, but introduces its own problems:

Long Polling Challenges

•Connection Churn — Each response closes the connection, requiring a new request. High-frequency updates mean constant reconnection overhead.
•Proxy and Load Balancer Issues — Many proxies timeout idle connections, requiring careful timeout tuning.
•Out-of-Order Delivery — Multiple long-poll requests can complete out of order, complicating state management.
•Header Redundancy — Full headers are re-sent with every request/response cycle.
•Sticky Sessions Complexity — Maintaining consistent routing across reconnects is challenging in distributed environments.

The Fundamental Insight

SSE Architecture: The Push Model

The Core Architecture

SSE establishes a unidirectional channel from server to client:

Converting Mermaid diagram...

How SSE Works Under the Hood

Connection Establishment: The client creates an EventSource object pointing to an SSE endpoint. This initiates a standard HTTP GET request.
Content-Type Negotiation: The server responds with Content-Type: text/event-stream, signaling that the response will be a continuous stream rather than a single response body.
Keep-Alive: The connection remains open. The server sends events whenever they occur, formatted according to the SSE protocol.
Automatic Parsing: The browser's EventSource API automatically parses incoming events and dispatches them to JavaScript handlers.
Automatic Reconnection: If the connection drops, EventSource automatically attempts to reconnect, resuming from the last received event.

SSE Protocol Example

HTTP Stream

HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache
Connection: keep-alive
 
: This is a comment (lines starting with colon are ignored)
 
data: Simple message with just data field
 
event: userJoined
data: {"userId": "123", "name": "Alice"}
 
id: 12345
event: stockUpdate  
data: {"symbol": "AAPL", "price": 178.50}
data: {"change": "+1.2%"}
retry: 5000
 
id: 12346
event: stockUpdate
data: {"symbol": "GOOG", "price": 141.20}

Protocol Simplicity

The SSE Protocol in Depth

The Server-Sent Events protocol defines a simple text-based format for streaming events. Understanding this format is crucial for implementing robust SSE systems.

Message Fields

Each event can contain the following fields:

SSE Message Fields
Field	Purpose	Behavior
data:	Event payload (required)	Multiple data lines are concatenated with newlines. Triggers dispatch when message completes.
event:	Event type name	Determines which event listener receives the message. Defaults to 'message' if omitted.
id:	Event identifier	Sets lastEventId. Sent to server on reconnection via Last-Event-ID header.
retry:	Reconnection delay (ms)	Tells client how long to wait before reconnecting after disconnect.
:	Comment	Ignored by client. Useful for keep-alive pings to prevent connection timeout.

Message Parsing Rules

The SSE parser follows precise rules that enable reliable streaming:

•Line Parsing: Stream is parsed line-by-line. Lines ending in LF, CR, or CRLF are recognized.
•Field Extraction: Each line is split at the first colon. The text before is the field name; after (minus optional leading space) is the value.
•Data Accumulation: Multiple data: lines within an event are joined with characters.
•Event Dispatch: A blank line signals the end of an event. The accumulated data is dispatched to handlers.
•Buffer Reset: After dispatch, the event data buffer is cleared for the next message.

Multi-Line Data Example

event: notification
id: msg-001
data: {
data:   "type": "alert",
data:   "title": "System Update",
data:   "body": "Maintenance scheduled for 3:00 AM UTC",
data:   "priority": "high"
data: }
 
event: heartbeat
data: ping

JSON Parsing Consideration

Client-Side Implementation

The browser's EventSource API provides a robust, production-ready interface for consuming SSE streams. Understanding its features enables building reliable real-time applications.

Basic Usage

eventsource-basics.js
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
// Create connection to SSE endpoint
const eventSource = new EventSource('/api/events');
 
// Handle generic messages (event: field omitted or set to 'message')
eventSource.onmessage = (event) => {
    const data = JSON.parse(event.data);
    console.log('Message received:', data);
    console.log('Event ID:', event.lastEventId);
};
 
// Handle specific event types
eventSource.addEventListener('notification', (event) => {
    const notification = JSON.parse(event.data);
    showNotification(notification.title, notification.body);
});
 
eventSource.addEventListener('stockUpdate', (event) => {
    const update = JSON.parse(event.data);
    updateStockTicker(update.symbol, update.price);
});
 
// Connection lifecycle events
eventSource.onopen = () => {
    console.log('SSE connection established');
    updateConnectionStatus('connected');
};
 
eventSource.onerror = (error) => {
    if (eventSource.readyState === EventSource.CONNECTING) {
        console.log('Reconnecting to SSE...');
    } else if (eventSource.readyState === EventSource.CLOSED) {
        console.error('SSE connection failed permanently');
        handleConnectionFailure();
    }
};
 
// Clean up when no longer needed
function cleanup() {
    eventSource.close();
    console.log('SSE connection closed');
}

EventSource Ready States

The readyState property indicates the connection status:

EventSource Connection States
State	Value	Description
CONNECTING	0	Connection is being established or reconnection is in progress.
OPEN	1	Connection is active and receiving events.
CLOSED	2	Connection is closed and will not reconnect automatically.

Authentication Consideration

Server-Side Implementation

Implementing an SSE server requires understanding HTTP streaming, connection management, and event formatting. Let's examine implementations across popular frameworks.

SSE Server Implementations

const express = require('express');
const app = express();
 
// Store connected clients
const clients = new Map();
let clientIdCounter = 0;
 
// SSE endpoint
app.get('/api/events', (req, res) => {
    // Set SSE headers
    res.setHeader('Content-Type', 'text/event-stream');
    res.setHeader('Cache-Control', 'no-cache');
    res.setHeader('Connection', 'keep-alive');
    res.setHeader('X-Accel-Buffering', 'no'); // Disable nginx buffering
    
    // Prevent request timeout
    req.setTimeout(0);
    
    // Send initial comment to establish connection
    res.write(': connected
 
');
    
    // Register client
    const clientId = ++clientIdCounter;
    clients.set(clientId, res);
    console.log(`Client ${clientId} connected. Total: ${clients.size}`);
    
    // Handle client disconnect
    req.on('close', () => {
        clients.delete(clientId);
        console.log(`Client ${clientId} disconnected. Total: ${clients.size}`);
    });
});
 
// Broadcast event to all clients
function broadcast(event, data, id = null) {
    const message = formatSSE(event, data, id);
    for (const [clientId, res] of clients) {
        res.write(message);
    }
}
 
// Format SSE message
function formatSSE(event, data, id = null) {
    let message = '';
    if (id) message += `id: ${id}
`;
    if (event) message += `event: ${event}
`;
    message += `data: ${JSON.stringify(data)}
 
`;
    return message;
}
 
// Send heartbeat every 30 seconds
setInterval(() => {
    for (const [clientId, res] of clients) {
        res.write(': heartbeat
 
');
    }
}, 30000);
 
// Example: broadcast stock updates
setInterval(() => {
    broadcast('stockUpdate', {
        symbol: 'AAPL',
        price: (170 + Math.random() * 10).toFixed(2),
        timestamp: new Date().toISOString()
    });
}, 5000);
 
app.listen(3000);

Critical: Response Buffering

Why One-Way Is Often Enough

The Hybrid Architecture Pattern

In practice, most real-time applications combine SSE for server push with regular HTTP for client-to-server communication:

Converting Mermaid diagram...

This pattern offers significant advantages over pure WebSocket implementations:

Benefits of SSE + HTTP

•Familiar Request-Response — Client actions use standard REST/HTTP, with proper status codes, caching, and error handling.
•Load Balancer Friendly — SSE works through standard HTTP infrastructure without special configuration.
•Connection Efficiency — One persistent SSE connection handles all server updates; HTTP/2 multiplexes client requests.
•Simple Authentication — Client requests use standard auth headers; only SSE needs special handling.
•Automatic Retry Logic — EventSource handles reconnection automatically, with exponential backoff.

Ideal Use Cases

•Live Feeds — News, social media, sports scores—where updates flow in one direction.
•Dashboards — Real-time metrics, monitoring UIs, admin panels.
•Notifications — System alerts, user mentions, activity updates.
•Progress Tracking — Long-running jobs, file processing, build pipelines.
•Stock Tickers — Financial data where clients only consume, never produce.

Design Principle

Summary: One-Way Server Push

We've established the foundational concepts of Server-Sent Events and the one-way push model. Let's consolidate the key takeaways:

Key Takeaways

•Polling is inefficient — Both short and long polling waste resources and introduce latency. Server push eliminates these problems.
•SSE uses standard HTTP — No special protocols or ports. Works through firewalls, proxies, and existing infrastructure.
•The protocol is simple — Text-based format with data, event, id, and retry fields. Easy to debug and implement.
•EventSource is built-in — Browsers provide native, production-ready SSE client with automatic reconnection.
•One-way is often optimal — Combined with HTTP for client-to-server communication, SSE covers most real-time scenarios.
•Hybrid architecture wins — SSE for push + REST for actions gives you the best of both worlds.

What's Next:

Page Complete