Why YouTube Uses Server-Sent Events (SSE) Over WebSockets: A Cost-Effective Architecture Decision

When you're serving 2 billion logged-in users per month like YouTube, every architectural decision has massive implications on infrastructure costs. Let's break down why YouTube chose Server-Sent Events (SSE) over WebSockets, and how this "simple" choice saves millions of dollars annually.

YouTube needs to push real-time updates to users:

Key insight: Notice something? All these are one-way communications - server to client. Users don't need to send continuous data back to the server.

Let's examine the infrastructure requirements and costs for each approach.

Connection Type: Full-Duplex (Two-way) Protocol: Custom WebSocket protocol Connection Management: Complex sticky sessions required

WebSocket Infrastructure:

2 billion users × 8KB memory per WebSocket = 16 TB RAM

• Dedicated WebSocket servers (can't easily share with HTTP)
• Special load balancer configurations
• CDN complexity/bypass costs = Massive infrastructure costs

Connection Type: Half-Duplex (One-way) Protocol: Standard HTTP/HTTPS Connection Management: Standard HTTP load balancing

SSE Infrastructure:

2 billion users × 2KB memory per SSE = 4 TB RAM

• Can share existing HTTP infrastructure
• Standard load balancing (no special config)
• CDN friendly (works like regular HTTP) = 75% less cost than WebSockets!

Let's do some back-of-the-envelope math for YouTube's scale:

WebSocket Approach:

Server Requirements:

• 10,000 dedicated WebSocket servers (10K connections each)
• Each server: $200/month
• Special load balancers: $5,000/month each × 100
• Monthly cost: $2,500,000

Memory: 100M × 8KB = 800 GB Bandwidth overhead: ~20% higher (WebSocket frame overhead)

SSE Approach:

Server Requirements:

• Can use existing HTTP infrastructure
• 3,000 servers handling multiple duties (33K connections each)
• Each server: $200/month
• Standard load balancers: Already in place
• Monthly cost: $600,000

Memory: 100M × 2KB = 200 GB Bandwidth overhead: Minimal (standard HTTP)

Annual Savings: ~$22.8 million 🎉

SSE provides several technical advantages that go beyond just cost savings.

One TCP connection can handle multiple SSE streams:

javascriptCopy
1// One TCP connection, multiple SSE streams
2GET /notifications → Stream 1
3GET /live-updates → Stream 2
4GET /chat → Stream 3
5// All over ONE TCP connection!

WebSockets require separate connections for each stream.

SSE handles reconnection automatically:

javascriptCopy
1// SSE handles this automatically
2const eventSource = new EventSource('/events');
3// If connection drops, browser auto-reconnects
4// and sends Last-Event-ID to resume from where it dropped

With WebSockets, you must implement this yourself with manual retry logic and state tracking.

SSE uses standard HTTP, so it works seamlessly with:

WebSockets often get blocked or require special configuration.

YouTube's existing infrastructure:

No need for separate WebSocket infrastructure!

Let's examine a bidirectional chat application at scale:

Advantages:

• ✅ Native bidirectional support
• ✅ Lower latency for client → server

Disadvantages:

• ❌ More complex infrastructure
• ❌ Higher memory per connection

Approach:

• ✅ SSE for server → client messages
• ✅ Regular HTTP POST for client → server messages
• ✅ Simpler infrastructure
• ✅ Lower memory usage
• ⚠️ Slightly higher latency for client messages (negligible for chat)

Verdict: For most chat applications, SSE + POST is still more cost-effective!

WebSockets introduce several hidden operational costs.

WebSocket Problem:

User connects to Server A Server A goes down User gets routed to Server B WebSocket connection lost → Must reconnect

SSE Solution:

User connects to any server Server goes down → Auto-reconnects to any available server No session stickiness needed!

Adding new WebSocket servers:

1. Update load balancer config
2. Ensure session persistence
3. Drain existing connections
4. Test sticky session routing
5. Monitor connection distribution

Adding new SSE servers:

1. Add server to pool
2. Done! ✅

WebSocket debugging:

• Custom tools needed
• Binary frames harder to inspect
• Connection state tracking complex

SSE debugging:

• Standard HTTP tools work
• Plain text events
• curl works out of the box!

By choosing SSE, YouTube gets:

Let's compare the implementation complexity:

javascriptCopy
1// Requires special WebSocket library
2const WebSocket = require('ws');
3const wss = new WebSocket.Server({ port: 8080 });
4
5wss.on('connection', (ws) => {
6    // Manual ping/pong for health check
7    ws.isAlive = true;
8    ws.on('pong', () => ws.isAlive = true);
9    
10    // Send message
11    ws.send(JSON.stringify({ type: 'notification', data: '...' }));
12});
13
14// Manual cleanup of dead connections
15setInterval(() => {
16    wss.clients.forEach((ws) => {
17        if (!ws.isAlive) return ws.terminate();
18        ws.isAlive = false;
19        ws.ping();
20    });
21}, 30000);

javascriptCopy
1// Uses standard HTTP
2app.get('/events', (req, res) => {
3    res.setHeader('Content-Type', 'text/event-stream');
4    res.write('data: notification\n\n');
5    // Connection cleanup handled by HTTP layer
6});

SSE is literally 4 lines vs 20+ lines for the same functionality!

For YouTube's use case:

SSE is the obvious choice.

WebSockets are great for:

• Real-time multiplayer games (constant bidirectional data)
• Collaborative editing (like Google Docs)
• Trading platforms (microsecond latency matters)

But for notifications, updates, and feeds? SSE saves millions while being simpler.

Ask yourself:

Rule of thumb: Start with SSE. Only upgrade to WebSockets when you have a proven need for bidirectional real-time communication.

YouTube didn't choose SSE because it's "good enough" - they chose it because it's the optimal solution for their specific needs. When serving billions of users, every architectural decision matters, and SSE provides the perfect balance of simplicity, cost-effectiveness, and scalability.

For most applications requiring real-time server-to-client updates, SSE is not just a viable option—it's often the best choice. The cost savings, operational simplicity, and infrastructure reuse make it a compelling solution for any application at scale.