Planning Swamp Dice for a crowd
A practical look at what concurrent use means for Swamp Dice, what the current 2 CPU and 2 GB production server can reasonably support, and how evidence—not optimism—will guide growth.
Concurrent does not mean identical
A signed-in player thinking between rolls, a spectator watching the tournament board, and a player actively rolling do not place the same demand on the platform. That distinction matters. Casual play produces short bursts of work. Tournament play adds live standings, shared scoring, and more frequent refreshes. A big-screen broadcast adds viewers but performs mostly read-only work. Capacity planning therefore starts with a mix of real behaviors, not a single oversized visitor number.
Our responsible starting range
With the production server now at 2 CPU and 2 GB of memory, and assuming Redis continues handling session and cache activity while application workers stay within a measured memory budget, our current planning range is roughly 150 to 250 actively playing casual users, or about 60 to 80 players and broadcast viewers combined during a highly active tournament. A larger group—perhaps 300 to 500 people—can be present when most are signed in, reading, waiting, or watching rather than constantly submitting gameplay actions. These are operating estimates, not promises or hard limits.
The launch line is deliberately lower
For the first broad events, the comfortable target is about 60 concurrent tournament participants or 150 active users across the platform. Starting below the estimated ceiling gives the database, queue, cache, and web workers room to absorb short spikes. It also gives us clean evidence about the difference between normal play, championship moments, notification bursts, and spectators refreshing the live broadcast.
What we will watch
Systems Command will track processor and memory pressure, database response time, queued and failed work, request errors, and service availability. The Swamp Dice Balance Lab remains focused on the game itself: participation, completed games, scoring distribution, banking behavior, Gator Bait, Hot Dice, repeat play, and competition activity. Keeping platform health and game balance separate makes it easier to tell whether a tense tournament is stressing the server or simply changing player strategy.
How we grow from evidence
Before raising the operating range, we will run staged tournament tests and compare live response times with the server’s actual resource use. If sustained demand approaches the comfortable range, the first steps are measured worker tuning, query and refresh optimization, and a larger server. Beyond that, background work, database capacity, and real-time broadcast delivery can be separated as needed. The goal is not to claim an impressive number; it is to keep every roll responsive and every score trustworthy as the crowd grows.