Vaccine sign-up surge

The brief

A county opens 80,000 vaccine appointments at 8 am. Within seconds, thousands of people reload and bots try to grab slots. The site must stay up, never sell the same slot twice, and be fair to people on a phone with a poor signal.

Think of a county vaccine sign-up site.

Users, scale and requirements

Who uses it

4 million residents; 600,000 try on launch day (approx.)

Audience in plain numbers

600,000 users or devices

Normal peak

≈ 300 requests per second

Request mix

Read: 55.7%; Search: 15%; Write: 10%; Sign-in: 15%; Notification: 0.3%; Analytics event: 4%

Speed for 99 of 100 requests

Read: ≈ 700 ms; Search: ≈ 600 ms; Write: ≈ 700 ms; Sign-in: ≈ 1,000 ms

Successful requests

99.5%

Data safety

No acknowledged write may be lost.

Monthly budget

≈ $58,000

Data at rest

≈ 1 TB

Where users are

North America: 100%

Home region

North America

Waiting deadlines

Read: 900 seconds; Search: 900 seconds; Write: 3,600 seconds; Sign-in: 900 seconds; Notification: 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.

Personal reads

40% of reads are private; a shared public copy cannot answer them.

Required proofs

Signed-in access; Tested backups; Audit trail

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

• Base traffic is about a tenth of the peak number; the 8 am rush multiplies it.
• The event is a one-off, so capacity you rent for an hour counts only for an hour.
• Notification speed measures provider acceptance. Device receipt is outside this traffic model; check expiry, provider outcome and retries in the correctness trace before claiming delivery guarantees.

Questions that shape the design

How many people show up at once?

About forty times the usual traffic for the first fifteen minutes after 8 am, then it falls back.

Is it fine to make people wait?

Yes, if it is fair and clear. A short wait is better than an error page. Failing and reloading makes it worse.

Are bots a problem?

Yes. Scripts try to book many slots and resell them. About half as much bot traffic as human traffic shows up a few minutes in.

What if the database fails mid-rush?

Bookings must not be lost or doubled. A short stall is acceptable; a wrong slot count is not.

The traffic day

A quiet baseline followed by the scheduled rush. The clock covers 00:00 to 24:00 in the home region. Events add pressure on top of that normal traffic.

1. 08:00 · Flash crowd

   A scheduled launch brings a sudden rush of requests.

   Traffic reaches 40 times the scheduled load; rises over 20 seconds, holds for 900 seconds and eases over 1,800 seconds.

2. 08:05 · Bot scraping

   Bots try stolen passwords and scrape pages, adding unwanted traffic.

   Extra attack traffic is 0.5 times the configured peak. Duration: ≈ 3,600 seconds.

3. 08:20 · Database failover

   The primary database dies. Recovery depends on the standby and failover settings.

   Duration: ≈ 90 seconds.

What a strong design has to handle

• The slot list is the same for everyone. Which element can answer thousands of people with one copy that is a few seconds old?
• Allocate each appointment once while preserving fair retryable admission.
• A 5-second CDN copy of the slot list may show a slot that has just gone. The booking step is the source of truth, so the worst case is a polite "that slot was just taken".
• The rate limiter will turn away a few honest people who reload quickly. That is the price of keeping the site up for everyone else.

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

• Saying "slow down" politely
• Waiting instead of breaking