When a game-winning goal happens, millions of fans expect to see it on their screens instantly. A delay of even a few seconds breaks the experience and frustrates users across web browsers, mobile apps, and living room TVs. This is the challenge of building a real-time scoreboard system, and solving it requires rethinking how data flows from the moment an event occurs to the moment it reaches every connected device.
Architecture Overview
A live sports scoreboard system lives at the intersection of three critical demands: extreme scalability, minimal latency, and reliability. The architecture typically consists of four layers working in concert.
At the foundation sits your data ingestion layer, where official score updates originate. This might be a referee's app, a stadium scoring system, or a sports league's official feed. Rather than have every client poll for updates, you push data into a message broker like Kafka or RabbitMQ. This decouples the source of truth from the distribution problem and creates a durable queue that can handle traffic spikes when major plays happen.
The real-time delivery layer is where the magic happens. WebSocket connections allow clients to maintain open channels with your backend, enabling bidirectional communication without the overhead of repeated HTTP requests. For scale, you'll want to distribute these connections across multiple servers behind a load balancer. Each server can typically handle thousands of concurrent connections, so with proper sharding, you can reach millions of users. Behind this layer, a pub-sub system like Redis or a dedicated service mesh synchronizes state across all connection servers, ensuring that when one server receives an update, all others broadcast it to their connected clients.
The application layer validates and processes updates. A lightweight service receives messages from your message broker, applies business logic, and publishes to the pub-sub system. This separation prevents invalid data from reaching users and gives you a clean point to add features like duplicate detection or geographic distribution.
Finally, the client layer implements listeners on web, mobile, and TV platforms. Each client maintains a WebSocket connection and renders updates as they arrive. Graceful fallbacks to Server-Sent Events or polling ensure compatibility across older devices.
Design Decision: Why Not Just Cache Everything?
You might wonder why you can't simply store everything in a distributed cache like Redis and have clients poll it. The answer is scale and latency. Polling creates unnecessary load, especially when you have millions of concurrent users. Each poll is a database hit, and coordinating timing across millions of clients is impossible. Push-based architecture eliminates this problem entirely.
Design Insight: The One-Second Challenge
Achieving sub-second latency across millions of users requires eliminating bottlenecks at every layer. First, use in-memory message brokers with minimal serialization overhead, avoiding JSON parsing when possible. Second, co-locate your real-time servers geographically close to users, so network round-trip times stay under 100 milliseconds. Third, implement connection pooling and batch processing to reduce database queries. Fourth, use edge servers or content delivery networks to handle connection termination closer to end users, rather than routing everything through a central data center. Finally, monitor end-to-end latency with synthetic clients and set up alerts for degradation. When architecture is designed this way, updates typically propagate within 200-500 milliseconds, comfortably beating the one-second target.
Watch the Full Design Process
Curious how these architectural decisions come together in practice? Watch the live design session where we built this system in real-time, exploring trade-offs and optimizations as we went:
Try It Yourself
Want to design your own real-time system? Head over to InfraSketch and describe your system in plain English. In seconds, you'll have a professional architecture diagram, complete with a design document. Whether you're tackling live scoreboards, notifications, or collaborative tools, InfraSketch transforms your ideas into visual architectures that you can iterate on and share with your team.
This is Day 72 of our 365-day system design challenge. Come back tomorrow for another architecture exploration.
Top comments (0)