Battle royale launch

The brief

On launch night millions of players queue for matches of 100. Each match streams positions many times a second, the lobby shows the live player count, and one patch notes page is opened by everyone. Connections must stay open, a match server dying must preserve acknowledged progress within the stated recovery point, and a few hot items, like the daily reward, are hit by everybody.

Think of a 100-player last-one-standing game on launch night.

Users, scale and requirements

Who uses it

5 million players a month (approx.)

Audience in plain numbers

5,000,000 people per month

Normal peak

≈ 15,000 requests per second

Request mix

Message: 65%; Read: 15%; Write: 10%; Sign-in: 5%; Analytics event: 5%

Speed for 99 of 100 requests

Message: ≈ 450 ms; Read: ≈ 450 ms; Write: ≈ 450 ms; Sign-in: ≈ 1,000 ms

Successful requests

99.9%

Data safety

At most 1 minute of writes may be lost.

Monthly budget

≈ $16,000

Data at rest

≈ 2 TB

Where users are

North America: 40%; Europe: 35%; Asia Pacific: 25%

Home region

North America

Waiting deadlines

Message: 900 seconds; Read: 900 seconds; Write: 3,600 seconds; Sign-in: 900 seconds; Analytics event: 3,600 seconds

Fresh reads

People must see their own changes. At most 0.1% of reads may be stale in the model.

≈ marks an approximation, just as in the game. Waiting deadlines measure the age of queued work and are separate from interactive response time.

• A match has 100 players and sends about 10 position updates a second each (approx.).
• Everyone opens the lobby count and the daily reward (approx.).
• One app server handles about 1,000 requests a second (approx.).
• All numbers are rough approximations.

Questions that shape the design

How fast must positions arrive?

Within about 150 ms for players near the servers. Counting the trip across an ocean for everyone else, the target here is a 450 ms p99 (approx.).

If a match server dies, may the match be lost?

The match may be lost. At most the last 60 seconds of progress and rewards may need replay after a failure; earlier acknowledged progress must survive.

Can the lobby count be a little old?

Yes, a few seconds. It is the same number for everyone.

The traffic day

Consumer traffic, busiest in the evening. The clock covers 00:00 to 24:00 in the home region. Events add pressure on top of that normal traffic.

1. 20:00 · Viral spike

   A post blows up. Traffic climbs to several times normal within minutes.

   Traffic reaches 2 times the scheduled load; rises over 600 seconds, holds for 3,600 seconds and eases over 3,600 seconds.

2. 20:30 · Hot key

   One item gets a huge share of traffic: a celebrity profile, one product, one merchant.

   Affected share: 30%. Duration: ≈ 3,600 seconds.

What a strong design has to handle

• Players stay connected for minutes. Which part holds a connection open, and which part answers the same question for everyone?
• Assign one authoritative match owner and recover acknowledged progress within its loss boundary.
• Sending positions as small, frequent updates feels smooth but costs bandwidth; sending fewer, larger ones is cheaper and feels laggy.
• A five second copy of the lobby count is invisible to players and removes almost all of that load.

Make a prediction, run a full traffic day, then compare the result. The in-game editorial opens after a finished day and includes measured reference designs.

Concepts to practise

• Live sockets and presence
• When one item is popular