Try it. No sign-up.
Design for 5,000 users. Watch it break.
Choose your resources, predict what fills up first and run the simulation. Then find out why your design struggles.
Free. No sign-up. Runs in your browser. A simulation with estimated numbers, not a measurement of real servers.
5,000 people are using your app at the same time. Will it hold?
A small Twitter-like app. All at once, not in a day.
Goal: handle 5,000 users within the $700 budget.
The App server. The computer that runs your app's code. runs your code. The Database. Where your app's data is saved. saves your data. The cards on the right show what each part can do. A guess is optional.
The chart shows how long a request takes as more people arrive, from 0 to 5,000.
To pass, your design must be:
- Fast: p95. How long the slowest 1 in 20 requests take. If p95 is 500 ms, 19 of 20 requests were faster. under 500 ms
- Reliable: under 1% fail
- Room to spare: nothing over 70% Busy. How much of a part's time is used. 100% busy means it cannot take any more work.
- Cheap: under $700 a month
Build your design
Monthly budget: $700
What each part can do
Every request goes through these parts, one after the other. They change when you change the design, before you run anything.
- 1 app serverHow we get this.One request costs about 3 ms of the app's CPU, plus about 4.7 ms of database work on server 1, because the database shares its cores. One core does 1,000 ms of work a second.So 1 core passes about 130 requests a second. Each person sends a request every 5 seconds, so people = requests a second x 5. "Too busy" is where a part reaches 70% busy.These are estimates from published numbers, not measured on real servers.$37 a monthRuns your app's code. 1 Core. One worker inside a computer. More cores do more work at once. each
Passes up to about 130 Request. One tap or click from a person that your app has to answer. a second, about 650 people.
Too busy. A part is over 70% busy. It still works, but a small burst of people makes requests wait in a line. from about 450 people.
Not tested yet - Database (on server 1)How we get this.Without a computer of its own, every request costs server 1 an extra 4.7 ms of CPU for the database work (the average of reads and writes, with no cache).That is why the app server card shows fewer requests a second than the app code alone would. The app and the database fight for the same cores.These are estimates from published numbers, not measured on real servers.included in server 1Saves your data. It has no computer of its own: it uses server 1's cores
Every request also costs server 1 some Database. Where your app's data is saved. work, so the App server. The computer that runs your app's code. above passes fewer requests than it would alone.
Server 1 is too busy from about 450 people, with the database on it.
Shares server 1's meter
Watch it break: how long a request takes as more people arrive
Solid: the slowest 1 in 20 (p95). Faint: the typical request (p50). In millisecondsPress Run the simulation. The line shows how long a request takes as more people arrive, from 0 to 5,000.
0 people5,000 people onlineThe rules, in full
- Fast. p95. How long the slowest 1 in 20 requests take. If p95 is 500 ms, 19 of 20 requests were faster. means 19 of every 20 requests finish within this time. Only the slowest 1 in 20 takes longer. The limit is 500 ms.
- Reliable. Fewer than 1% of requests may fail.
- Room to spare. No part may be more than 70% busy. Why 70%? A part that is 97% busy looks fine until traffic grows by 3%. Then requests queue up and everything slows down.
- Cheap. Under $700 a month.
5,000 people online × 1 request every 5 s = 1,000 requests a second, 20 reads for every write. These are people online at the same time, not visitors in a day: a few thousand online at once is tens of thousands of visitors a day.
The numbers behind the result
Requests every second: sent, Throughput. How many requests the app finishes every second., and the most it can finish
Dotted: requests people sent. Solid: requests the design finished. Faint: the most it can finishAfter the run you see how many requests a second were sent, and how many the design finished. When the design is full, the finished line flattens while the sent line keeps climbing.
0 people- People online
- -
- the most in this test
- Requests finished a second
- -
- sent and finished
- p50. The typical wait. Half of the requests were faster than this.
- -
- half were faster
- p95. How long the slowest 1 in 20 requests take. If p95 is 500 ms, 19 of 20 requests were faster.
- -
- limit 500 ms
- Failed requests
- -
- limit 1%
- Busiest part
- -
- none yet
Show the maths
- 1. The traffic5,000 users are online at the same time (concurrent users, not visitors). Each sends 1 request every 5 seconds.5,000 ÷ 5 = 1,000 requests per second at the peak.20 reads for every write: 952 reads and 48 writes per second.
- 2. What one request costs the app servers3 ms of app CPU per request (an assumption: a typical Node handler with auth, an ORM and JSON takes 1 to 10 ms).The database runs on server 1 and adds 4.71 ms of CPU there for every request (the reads and writes it is asked for, after the cache has answered what it can).1,000 requests × 7.71 ms = 7,714 ms of CPU every second = 7.7 cores.
- 3. What the app servers can do1 core works (Node processes, capped by vCPU), and each request costs 7.71 ms on it (3 ms app + 4.71 ms database). 1,000 ms ÷ 7.71 ms = 130 requests per second per core.1 × 130 = about 130 requests per second at 100% busy.At your goal that is 771% busy.
- 4. How many users it holdsFull: requests per second at 100% busy × 5 s = about 650 users.Safe line: 70% of that = about 455 users. A design passes only if no part is busier than 70% while the load is normal.Why 70%? Past it, a small burst makes the queue grow. The Cost lab sizes servers at 60% and databases at 70% for the same reason.This run stopped being safe at 458 users. The simple division above gives 455: the small difference comes from the load balancer and the second-by-second ramp.
- 5. Why latency climbsA request waits when all cores are busy. The p95 wait is ln(C ÷ 0.05) ÷ (capacity − load), with C the chance of waiting (Erlang C).On one server at the 70% safe line (91 requests per second) the p95 wait is about 68 ms. At 97% busy it is 762 ms, and it grows without limit as the load nears 100%.Total latency = 20 ms base + the service time + the waits. We add up the p95 waits of the queues on the path, which is a little pessimistic (the true p95 of a sum is lower).The test fails at p95 over 500 ms or more than 1% errors.
- Where the numbers come fromEstimated from published benchmarks; to be calibrated. A model, not a measurement of real servers.Every number is tagged: S = a vendor document or benchmark, P = a list price, A = an assumption, Calc = worked out from those.
Estimated from published benchmarks; to be calibrated. A model, not a measurement of real servers. It teaches the shape of the problem: what fills up first, and why. It is estimated from published numbers, and not yet measured on real servers.
This is a small piece of Level 3: a simulation, plain code and not an AI. The same design gives the same result every time. It is estimated from published numbers, and not yet measured on real servers.
What it shows
Three things one test can teach you
These are the ideas an interviewer wants to hear you say out loud. Watch the numbers change each time you try a fix.
- 01
One part fills up first
When the people arrive, one part fills up before the others. That part sets how many people you can serve, however big the rest is. Keep every part under 70% busy. Past that, a small burst makes requests wait in a line.
- 02
Fixing one bottleneck can move the problem
Give the database its own computer and the problem moves to the database. Add a cache and it moves back to the servers. You never remove it. You move it to somewhere cheaper.
- 03
Money is a limit too
A bigger box always works. The skill is to hold the load inside a budget, and to say which part you would grow next, and why.
Where next
Ready for the next challenge?
All of these are free.
Questions
Before you play
Is this a real load test?
No. It is a model that runs in your browser, not a test on real servers. The numbers are estimated, so use it to learn what fills up first and why.
Do I need an account?
No. Not for this page, and not for any of the eight levels. The whole test runs in your browser tab. You can change the design as many times as you like without signing up.
Why does my design fail?
p95 is the time that 19 of every 20 requests beat. Only the slowest 1 in 20 takes longer. A design "falls over" when p95 goes over 500 ms or more than 1 in 100 requests fail. It is "too busy" when any part is more than 70% busy while the traffic is normal: it still works, but a small burst makes requests wait. To pass, it must do neither, and it must stay inside the budget.
Why a $700 budget?
A bigger box always works, so a budget makes you choose. The skill is to hold the load inside a limit of $700 a month, and to say which part you would grow next, and why.
Can I keep changing my design?
Yes. Change anything and the test runs again, so you can see what each change did. Your design stays in this browser, on your device.
Is there an AI in it?
No. The load test is plain code. The same design on the same numbers gives the same result every time, and it costs nothing to run.
Can I practise this in an interview?
Yes. The simulator interview asks about your design and tests your claims in the simulator. It needs a free account and uses one of your AI mocks.
What are an app server, a database and a cache?
An app server is the computer that runs your app's code. A database is where your app's data is saved. A cache is a fast copy of popular data kept in memory, so the database is asked less. A core is one worker inside a computer: more cores do more work at once.
Is it like real servers?
It is a model, not a copy of production, and it is not a load test on real servers. The numbers are estimated from published benchmarks and AWS list prices, and they are not yet calibrated on a real server. Each part shows the number it uses and where it comes from, and "Show the maths" lets you redo the result with a pencil. It teaches the shape of the problem: what fills up first, and why. Use it to build the instinct, not to size your real servers.
What does "5,000 users" mean?
5,000 users online at the same time, each sending one request every 5 seconds: 1,000 requests a second. It is not 5,000 visitors in a day. A few thousand people online at once is tens of thousands of visitors a day.
What do you keep about me?
Your design stays in this browser, on your device. We count how many runs finish and how many people click sign-up, as two plain numbers with no name, no account and no address in them. If your browser sends Do Not Track, we do not count you.
Want to practise explaining your design?
All eight levels are free, with no account. Create a free account to try an AI simulator interview: the interviewer asks about your design and tests your claims in the simulator. The simulator stays free either way.