Scaling WebSockets for Real-Time Feeds

Introduction

Developing sports technology SaaS engines requires distributing live updates to massive global audiences. Unlike traditional request-response HTTP web servers, live matches rely on persistent full-duplex TCP WebSockets. Scaling these connections demands specific network topology modifications, load balancing, and lightweight server processes.

1. Redis Pub/Sub Broadcast Architecture

To avoid memory exhaustions from duplicate database reads, we utilize a single-writer broadcast model. Scorekeepers update a central database write-instance. This write triggers a Redis Pub/Sub channel, sending a singular JSON update packet to all cluster nodes. The nodes then copy and broadcast the update to active WebSockets, capping database read counts at 1 per ball event.

2. Load-Balancing & Reverse Proxy Setup

Persistent TCP connections render traditional round-robin HTTP load balancers ineffective. We implement NGINX reverse proxies configured with IP-hash session stickiness and keep-alive socket allocations. This splits connections uniformly across Node.js/Go cluster nodes, preventing individual nodes from exceeding OS file descriptor maximums.

3. Buffer Size & Memory Optimization

With 100,000 active clients, a minor 10KB socket buffer allocations increase memory usage by 1GB. We configure custom WebSocket framing with minimal payloads, using numeric dictionaries rather than verbose JSON strings, resulting in average socket allocations of under 2KB per connection.

For additional information regarding our real-time telemetry and WebSocket infrastructure packages, contact our engineering department.