Sports Betting Software Scalability: From 100 to 100,000 Players
A sports betting software platform that handles 100 concurrent players is a different product from one that handles 100,000. WSGaming explains the architecture decisions that determine whether your sportsbook scales — and the ones that create bottlenecks you only discover during a major event.
Most operators experience their first scaling failure during a major event — Champions League final, World Cup knockout stage — when traffic spikes 10–50x normal levels and the platform architecture that worked fine for 500 concurrent users fails at 5,000. By this point, the operator has players, marketing spend, and brand reputation invested. Discovering a non-scalable architecture at this stage is expensive.
Bottleneck 1: The Database Write Bottleneck
Bet placement creates database write operations. At 100 concurrent players during a live match, bet write frequency might be 10–20 per second — handled easily by a single database instance. At 10,000 concurrent players during a Champions League final, bet write frequency can reach 500–2,000 per second — a single database instance becomes the primary bottleneck.
WSGaming’s sports betting software uses a write-optimised database architecture with connection pooling and write queuing that maintains sub-200ms bet acceptance response times at 10,000+ concurrent write operations per second. Your API connection to WSGaming scales independently — WSGaming’s infrastructure scales horizontally, not your platform.
Bottleneck 2: WebSocket Connection Limits
Each player watching a live odds board maintains a WebSocket connection (directly or indirectly) to receive odds updates. At 100 players, 100 connections is trivial. At 100,000 players, 100,000 concurrent WebSocket connections requires load-balanced WebSocket infrastructure with session affinity.
The correct architecture fans out odds updates from a single API connection (WSGaming → your server) to all connected players via your own internal WebSocket or Server-Sent Events infrastructure. Your server maintains one WebSocket to WSGaming and distributes updates to 100,000 players — WSGaming’s infrastructure does not see 100,000 connections, only one.
Bottleneck 3: Synchronous Settlement Processing
Settlement events arriving after a match affect potentially thousands of bets simultaneously. If your settlement handler processes bets synchronously (one at a time), a 10,000-bet settlement queue takes time proportional to queue length — during which players see unsettled bets and flood support. Asynchronous, parallelised settlement processing with immediate player notification (even before the payout calculation completes) is the correct architecture for scale.
Scaling Stages: What Changes and When
| Player Count | Primary Bottleneck | Architecture Change Required |
|---|---|---|
| 0–500 | None significant | Single server, standard config |
| 500–5,000 | Database write frequency | Connection pooling + read replicas |
| 5,000–20,000 | WebSocket fan-out | Dedicated WebSocket server layer |
| 20,000–100,000 | Async settlement | Queue-based settlement processing |
| 100,000+ | All of the above | Horizontal scaling across all layers |
Key Takeaways
- Database write bottleneck is the first scaling failure point — appears at 500–5,000 concurrent players
- WebSocket fan-out architecture (one API connection → many players) is essential above 5,000 concurrent users
- Synchronous settlement processing fails at scale — implement async queue-based settlement before you need it
- WSGaming’s infrastructure scales horizontally independently of your application layer
- Build for 10x your current scale at each architecture milestone — you will be there sooner than you expect
Discuss Your Scaling Architecture With WSGaming
Our technical team will review your current platform architecture and identify bottlenecks before you hit them during a major event.
Book Architecture ReviewView Sports Betting Software