Skip to content
System Designer

Medium · Government and education

Course enrollment day

Registration opens at 9 am for 40,000 students, and a handful of popular courses have only 30 seats each. Everyone clicks "enroll" at the same moment, and when the page is slow they click again. A seat must go to exactly one student. Practise this medium system design problem for free with a Google or GitHub account.

The brief

Registration opens at 9 am for 40,000 students, and a handful of popular courses have only 30 seats each. Everyone clicks "enroll" at the same moment, and when the page is slow they click again. A seat must go to exactly one student.

Think of a university's registration day.

Users, scale and requirements

Who uses it
40,000 students, 12 courses each (approx.)
Audience in plain numbers
40,000 users or devices
Normal peak
≈ 4,000 requests per second
Request mix
Read: 52%; Search: 20%; Write: 12%; Sign-in: 15%; Notification: 1%
Speed for 99 of 100 requests
Read: ≈ 650 ms; Search: ≈ 500 ms; Write: ≈ 650 ms; Sign-in: ≈ 1,000 ms
Successful requests
99.9%
Data safety
No acknowledged write may be lost.
Monthly budget
≈ $38,000
Data at rest
≈ 0.2 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
Personal reads
40% of reads are private; a shared public copy cannot answer them.
Required proofs
Signed-in access; Tested backups

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

  • A "write" is an enroll, a drop or a swap.
  • Seat counts shown on the page may be a little behind; the booking is exact.
  • 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 wrong can the seat count shown on the page be?

A few seconds late is fine. The final check happens when you press enroll.

Can a student enroll twice in the same course?

No. A repeated click or a retry must not count twice, and must not take two seats.

What happens at 9:00?

About twelve times normal traffic for fifteen minutes, with a third of all lookups going to the same few courses.

Do students retry on errors?

Yes. When a page fails they click again quickly, which makes things worse.

The traffic day

Traffic concentrated in working hours. The clock covers 00:00 to 24:00 in the home region. Events add pressure on top of that normal traffic.

  1. 09:00 · Flash crowd

    A scheduled launch brings a sudden rush of requests.

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

  2. 09:00 · Hot key

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

    Affected share: 30%. Duration: ≈ 1,800 seconds.

  3. 09:05 · Retry storm

    A brief failure causes clients to retry, adding load while the service recovers.

    Failed calls: 90%. Duration: ≈ 30 seconds. Duration: ≈ 1,200 seconds.

What a strong design has to handle

  • A third of the traffic wants the same few rows. What keeps one row from being the whole database's problem?
  • Allocate the last course seat atomically and make enrollment retries safe.
  • A strict queue grants seats in order and keeps the database calm, but each student waits a moment longer to hear "you got in".
  • A 5-second page copy can show "1 seat left" when it is gone; the queue decides, and the student sees a clear message.

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

Related problems