Skip to content
System Designer

Medium · Core building blocks

Login and single sign-on

Employees and customers sign in to many apps through one account. Most of the day is quiet, then 9 am arrives and everyone signs in at once. Attackers also hammer the login with stolen passwords. Let real people in quickly and keep the rest out. Practise this medium system design problem for free with a Google or GitHub account.

The brief

Employees and customers sign in to many apps through one account. Most of the day is quiet, then 9 am arrives and everyone signs in at once. Attackers also hammer the login with stolen passwords. Let real people in quickly and keep the rest out.

Think of the "Sign in with" button used by many apps.

Users, scale and requirements

Who uses it
8 million people a month (approx.)
Audience in plain numbers
8,000,000 people per month
Normal peak
≈ 6,000 requests per second
Request mix
Read: 70%; Sign-in: 30%
Speed for 99 of 100 requests
Read: ≈ 300 ms; Sign-in: ≈ 1,000 ms
Successful requests
99.9%
Data safety
No acknowledged write may be lost.
Monthly budget
≈ $63,000
Data at rest
≈ 0.2 TB
Where users are
North America: 60%; Europe: 40%
Home region
North America
Waiting deadlines
Read: 900 seconds; Sign-in: 900 seconds
Fresh reads
People must see their own changes. At most 0.1% of reads may be stale in the model.
Required proofs
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.

  • Use the peak and request mix to split sign-ins from session checks.
  • A password check is deliberately slow and costs real compute.
  • All numbers are rough approximations.

Questions that shape the design

Do apps check a session on every click?

Yes, so session checks are far more common than logins. They must be fast.

Can a session check be a few seconds old?

Yes, if someone signs out, a few seconds of delay is acceptable. A password change must take effect soon.

What about password guessing?

Limit attempts per account and per address, and log every attempt for audit.

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. 10:30 · Bot scraping

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

    Extra attack traffic is 0.5 times the configured peak. Duration: ≈ 7,200 seconds.

  2. 09:00 · 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

  • Signing in is rare and heavy. Checking a session is frequent and light. Should they take the same path?
  • Validate and revoke sessions without turning every click into a fragile login.
  • Session checks served from a fast store are quick, but a signed-out session may linger for a few seconds.
  • Strict attempt limits stop guessing, but can lock out a real user whose account is being attacked.

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