Practice: Scaling a Ticket Sale

Normal traffic all month, then fifty times that for ten minutes at noon.

Scaling up against out, statelessness and the autoscaling gap all meet on one ticket sale here. Write your plan for each question before opening the answer.

The brief. A ticketing site normally runs on three application servers and one database at 30% busy. Once a month, tickets for a large concert go on sale at noon, and for ten minutes traffic is fifty times normal. The servers keep each user's place in the queue in their own memory. A new server takes about four minutes to be ready.

What must change before adding servers will work at all?
Can autoscaling handle the noon spike? If not, what does?
What will limit the site once the application tier is large enough?

Check your plan

Move each user's place out of server memory into a shared store. Otherwise a request on another server loses the user's place, and adding servers makes it worse.
No. The spike arrives in seconds and lasts ten minutes; new servers take four. Scale ahead on a schedule, to roughly fifty times the usual tier, a few minutes before noon, and scale back after.
The database. Fifty times the traffic sends it far more queries than a 30% load can absorb. Move it to a bigger machine for the sale, cache what every buyer reads, such as the event page, and consider a queue that admits buyers at a pace the database can take.

System Design
Performance

← → move through sections and cards