Photo: Taylor Vick / Unsplash
Launch night. The squad is on voice chat, the game is installed, and the main menu shows a queue number that barely moves.
Every studio has to guess how many players will show up on launch day. That guess is always wrong in one direction or the other, so most of the planning goes into what happens when it misses.
The forecast is always a range
Pokémon GO is the textbook case. In 2016 its engineers planned for a baseline of traffic and treated five times that baseline as the worst case. Real launch traffic hit 50 times the baseline, ten times the worst case anyone had written down.
After launch, during a move to Google's global load balancer, a second spike hit. When overloaded servers started returning errors, phones retried at the same moment, and those synchronized retries reached 20 times the previous global peak. Engineers call this a thundering herd. The fix was on the client side: random delays and exponential backoff, so each phone waits a little longer, and a little differently, before it tries again.
When the login screen is the bottleneck
There are two kinds of servers behind that menu screen.
-
Match servers run the match you actually play in, one per match or lobby. They're mostly independent of each other, so adding more is fairly simple.
-
Backend services handle login, matchmaking, inventory and the database holding everyone's progress. Every player touches them, and they all share one record of who owns what.
Helldivers 2 showed the difference in February 2024. Arrowhead capped the game at 450,000 concurrent users (CCU), then raised the limit to 700,000. "It's not a matter of money or buying more servers," CEO Johan Pilestedt said at the time. "It's a matter of labor. We need to optimize the backend code." Adding machines helps the match servers, but it does little for the shared backend every login has to go through.
The floor a studio still needs a month later
The first number a studio fixes is the floor. That's the capacity it expects to run every day once launch week is over, sized for the players who stick around rather than the crowd on day one.
There's no industry rule for how many players stay. A studio has to measure it, from its own betas, its own previous games, or comparable titles, and then commit to a figure for week four.
Here's the arithmetic, with made-up numbers. Say a load test shows one machine running 40 four-player match servers, so 160 players per machine. If the studio expects 40,000 concurrent players a month after launch, the floor is 250 machines.
That floor runs 24/7 for months, so studios usually put it on hardware rented at a flat monthly rate. An OVHcloud dedicated server is one example, billed by the month, with unmetered traffic outside Asia-Pacific and anti-DDoS protection switched on by default. Machines like these cost the same every month and take longer to add or remove, which suits a load that barely moves.
The catch is how big that floor ends up. If it's built for day one, it's mostly sitting idle by week four, and the studio is still paying for it.
The ceiling, and the queue behind it
On top of the floor sits an elastic layer that can grow and shrink within minutes. Open-source tools like Agones run this for game servers. Its fleet autoscaler keeps a buffer of ready servers, set as a fixed count such as 5 or a share such as 5%, between a minimum and a maximum size. A schedule policy can raise capacity ahead of a launch hour the studio already knows.
The maximum is the number that matters. It's a budget ceiling, agreed before launch, so a viral weekend can't produce an unlimited bill.
Once that limit is hit, the idea is to turn players away cleanly rather than let everything break. A login queue with a wait estimate is the part you see. Behind it, the backend can serve degraded responses, switching off leaderboards or cosmetic stores so that logins and matches keep working. A long queue on launch night often means the studio planned ahead. Without one, the server lets everyone in and then falls over.
Co-op games that run on players' own machines
Plenty of co-op games skip the fleet entirely. In a listen-server or peer-to-peer setup, one of you hosts the session and the rest of the squad joins directly.
A studio shipping that kind of game still runs accounts, matchmaking or invite codes, and cloud saves. Those services are where its launch risk sits, and they face the same choice between a queue and a crash, at a much smaller scale.
What each layer costs when the guess is wrong
-
Floor: sized for the week-four peak, usually on fixed machines such as a bare metal dedicated server rented by the month. Too high and the studio pays for idle hardware for months. Too low and the elastic layer carries everyday traffic it was meant to absorb only in bursts, so it reaches its budget cap sooner.
-
Ceiling: sized for the launch spike and scaled in minutes, up to the budget cap. Set it too low and the queue starts early.
-
Queue: sized for whatever gets past both. Players lose time and patience, while their accounts and progress stay safe.