WebSockets

WebSocket is a communication protocol that provides full-duplex, persistent connections between a client and server over a single TCP connection. Unlike HTTP (request-response), WebSocket allows both sides to send data at any time without the overhead of establishing a new connection for each message.

Why This Matters

WebSockets power real-time features: chat applications, live notifications, stock tickers, collaborative editing, and online gaming. Understanding when to use WebSockets vs HTTP polling vs SSE is a key system design decision.

The Building Blocks

• Full-duplex: Both client and server can send messages independently at any time.
• Persistent connection: After the initial HTTP upgrade handshake, the connection stays open. No repeated TCP/TLS handshakes.
• Low overhead: WebSocket frames have 2-14 bytes of header vs HTTP's 100+ byte headers per request.
• When to use: Real-time chat, live updates, collaborative editing, gaming, financial data streaming.
• When NOT to use: Standard CRUD APIs, infrequent updates, one-way data (use SSE instead).

Under the Hood

A WebSocket connection starts as a normal HTTP request with an Upgrade header. The server responds with 101 Switching Protocols, and the connection is upgraded to WebSocket. From this point, both sides can send messages freely. The connection persists until explicitly closed by either side.

Scaling WebSockets is harder than scaling HTTP because connections are stateful. You need sticky sessions or a pub/sub system (Redis) so any server can push messages to any connected client.

How Companies Actually Do This

Slack uses WebSockets for real-time messaging — every message, typing indicator, and presence update is delivered via WebSocket.

Figma uses WebSockets for real-time collaborative design, syncing cursor positions and design changes between users.

Binance streams real-time cryptocurrency prices to millions of connected clients via WebSocket.

Common Pitfalls

1. Using WebSockets for everything — simple API calls should use HTTP
2. Not handling reconnection — networks are unreliable, connections drop
3. Not implementing heartbeats — idle connections may be silently closed by firewalls/proxies

Interview Questions Worth Practicing

1. When should you use WebSockets vs HTTP long polling vs SSE?
2. How do you scale WebSocket connections across multiple servers?
3. How do you handle reconnection and message ordering?
4. What happens when a WebSocket server goes down?

The Tradeoffs

• WebSocket vs HTTP Polling: WS is real-time but stateful; polling is simpler but wastes bandwidth.
• WebSocket vs SSE: WS is bidirectional; SSE is server-to-client only but simpler and auto-reconnects.
• Scalability: Each WebSocket connection consumes a TCP socket. A single server can handle 100K-1M connections; beyond that, you need horizontal scaling with a message broker.

Related Topics

• long-polling-vs-websockets
• pub-sub
• http-https
• event-driven

The Real-World Incident That Made This Famous

Understanding Websockets became critical after multiple high-profile production incidents at major tech companies. When systems handle millions of users, even small misunderstandings about Websockets can lead to cascading failures that cost millions in lost revenue and erode user trust. Companies like Netflix, Google, Amazon, and Meta have all invested heavily in mastering Websockets because they learned the hard way that ignoring it leads to outages.

The key lesson from these incidents: Websockets is not just a theoretical concept — it is a practical skill that separates engineers who build resilient systems from those who build fragile ones.

How Senior Engineers Think About This

Senior engineers approach Websockets differently from textbook definitions. Instead of memorizing rules, they build mental models. They ask: "What problem does Websockets solve? When does it fail? What are the alternatives?" This problem-first thinking leads to better design decisions because every system has unique constraints.

When evaluating Websockets in a system design context, experienced engineers consider the failure modes first. What happens when this component goes down? How does the system degrade? Is the degradation graceful or catastrophic? These questions reveal more about your understanding than any textbook definition.

Common Interview Mistakes

Mistake 1: Giving a textbook definition without context. Interviewers want to see you connect Websockets to real systems and real problems.

Mistake 2: Not discussing trade-offs. Every design decision involving Websockets has trade-offs. Discuss what you gain and what you give up.

Mistake 3: Overcomplicating the solution. Start with the simplest approach to Websockets that meets the requirements, then add complexity only when justified.

Production Checklist

• Define clear metrics for measuring the effectiveness of your Websockets implementation
• Set up monitoring and alerting that specifically tracks Websockets-related failures
• Document your Websockets design decisions in Architecture Decision Records (ADRs)
• Test failure scenarios related to Websockets in staging before production deployment
• Review and update your Websockets implementation quarterly as system requirements evolve
• Train new team members on the specific Websockets patterns used in your system

Read the original source | Content from System-Design-Overview

Practical Implementation for .NET Developers

In a .NET application, you would typically implement this pattern using the following approach:

ASP.NET Core setup: Create a service class that encapsulates the logic, register it with dependency injection, and inject it into your controllers or minimal API endpoints. The built-in DI container handles lifecycle management.

Entity Framework Core: For database interactions, EF Core provides the ORM layer. Use migrations for schema management and raw SQL for performance-critical queries. Consider Dapper for read-heavy paths where EF Core's overhead matters.

Azure integration: If deploying to Azure, leverage managed services — Azure Cache for Redis, Azure SQL, Azure Service Bus, Azure Cosmos DB. These eliminate operational overhead and provide built-in monitoring through Application Insights.

Testing: Use xUnit with Testcontainers for integration tests that spin up real databases in Docker. Mock external dependencies with NSubstitute. The WebApplicationFactory class lets you test your entire HTTP pipeline in-process.

Monitoring: Add Application Insights telemetry to track request latency, dependency calls, and custom metrics. Use structured logging with Serilog to make production debugging possible:

Log.Information("Processing order {OrderId} for {CustomerId}", orderId, customerId);

This gives you searchable, structured logs in Azure Monitor or Seq.