Battlefield 6 launch server queues — what 500,000 players waiting tells you about load testing

When Battlefield 6 launched on 10 October 2025, millions of players hit the servers at once. EA expected the surge and deployed admission queues on purpose. Those queues still reached upwards of 500,000 players waiting at peak. That is the thundering-herd pattern at gaming scale, and it carries a direct lesson for any team preparing a high-concurrency launch.

What happened

On launch day, Battlefield 6 hit roughly 747,000 concurrent players on Steam alone. It was one of the largest simultaneous launches in recent memory and brought in approximately $100 million in Steam pre-orders. The backend could not take every connection attempt at once. Instead of letting authentication and session services fall over, EA routed the overflow into managed queues. Players waited, many of them for a long time.

The queues were intentional. EA’s developers publicly stated they were using queues “to protect the player experience” and were scaling capacity live. An open beta in August 2025 had already shown queue pressure, so the team saw the problem weeks before the full release. Launch-day queues still reached half a million.

The timeline

• 2025-08-07: The open beta launch causes visible server queues, an early sign of capacity pressure at full release.
• 2025-10-10: Full launch. Millions of players log in and establish sessions at nearly the same moment and overwhelm provisioned backend capacity within minutes.
• Peak queue depth: Queue lengths exceed 500,000 concurrent players and stay that long for hours while EA scales capacity live.
• Gradual recovery: EA adds server capacity during the day. Queues shrink as provisioning catches up with demand.

Why it happened

Provisioned backend capacity did not match the near-instant arrival of hundreds of thousands of login and session requests. A gradual traffic ramp is a different problem. Here every waiting player pressed the launch button at nearly the same moment, and each one tried to authenticate, load a profile and open a persistent session within seconds of the others.

The auth and session layer, which must respond before a player sees a lobby, is almost always the first bottleneck. Session state is usually stateful and expensive. Opening half a million sessions in a few minutes needs far more provisioning than keeping half a million sessions active over an afternoon.

EA’s queue infrastructure worked as load shedding, and that was the right engineering call. But queues that reached 500,000 players suggest that either the ceiling was set below the real arrival rate or autoscaling responded more slowly than the demand curve.

The failure pattern

This is a thundering-herd failure. A mass of clients tries to connect, authenticate or open sessions at the same moment, and the shared auth/session layer saturates before it can respond. The queue mitigates the problem. It does not remove it.

The pattern applies to any product with a synchronized launch: a game, a ticket sale, a seasonal product drop. The auth path looks fine under gradual load because users spread across the day. Under simultaneous arrival, it saturates first.

The academy’s spike test documentation covers the profile shape for simultaneous-arrival scenarios. To find the real ceiling, add the breakpoint capacity test: you run until something breaks, and that tells you where queuing or autoscaling must engage.

How it could have been prevented

Some engineering decisions add to the risk, and some reduce it:

Queue-first design, sized correctly. EA had queues. Size queue capacity and backend provisioning to the expected peak arrival rate, not an average. If you expect 700k concurrent arrivals, the queue ceiling and backend provisioning targets must account for that.

Pre-scaled capacity. Static pre-scaling to 2–3× the expected peak before launch removes autoscaling lag. If autoscaling has to react during the launch surge, it will be behind for the first several minutes.

Auth path as a first-class load target. Storefront read traffic and game session traffic have different profiles. Load-test the auth and session path on its own, at concurrent-login scale, not only inside a general load test.

Beta signals as acceptance gates. The August open beta showed queue pressure. If you instrument a beta like a load test (p95 auth latency, error rate against queue depth, autoscaling response time), you can turn that signal into a concrete capacity target for launch.

How to test for this with MaxoPerf

A thundering-herd launch test has two stages: a spike test and then a breakpoint run.

Stage 1: Spike test (thundering-herd model)

Target the login, session and lobby-entry path in your staging environment, not the storefront homepage. Those endpoints carry the stateful load.

Configure a k6 or Taurus scenario as a closed-model spike:

• Baseline: 1,000 virtual users for 2 minutes (warm-up).
• Spike: ramp to 50,000–100,000 virtual users over 60 seconds, hold for 5 minutes.
• Drop: ramp back to baseline to observe recovery behaviour.

Run from at least two managed geographic locations to model players arriving from different regions at once. In the results, watch:

• p95 and p99 auth latency at the spike edge. This is where the backend first feels the herd.
• Error rate: any rise above zero at spike onset means the ceiling is below the arrival rate.
• Queue depth (if your session layer emits it): queue depth that grows under a flat arrival rate means the service is falling behind.

Stage 2: Breakpoint capacity test

After the spike, run a step-load breakpoint capacity test on the same auth path:

• Start at 5,000 virtual users and step up by 5,000 every 3 minutes.
• Record the concurrency level where the error rate crosses 1% and where p99 latency crosses your SLO.
• That ceiling is your queue-engagement threshold: the point where your admission queue must take the overflow instead of letting requests hit the backend.

Schedule both tests to run automatically before any major release or patch that touches the session layer. If the ceiling drops, you want to know before your players do.

Key takeaways

• Queues are the right load-shedding tool at launch, but size them to the real arrival rate, not an average.
• In a thundering-herd scenario, the auth and session path saturates first. Test it on its own, not only as background traffic in a general load test.
• Pre-scaling before launch removes autoscaling lag during the surge. When the ramp is near-instant, static headroom is more reliable than reactive autoscaling.
• A beta is a free load test. Record queue depth, auth error rates and p95 latency during beta events and use those numbers as launch capacity targets.
• A breakpoint run on the auth path gives you a concrete ceiling. With that number from staging, your queue admission thresholds and pre-scaling targets rest on data instead of guesswork.

If you are planning a high-concurrency launch, start with MaxoPerf’s spike and breakpoint test types to build the testing profile described above.