Book a call, opens in a new tab

Scale planner: where your backend breaks first

Nobody can promise a capacity number without load testing your system against your data. This planner tells you where the pressure lands first as traffic grows, and what to change before you find out the hard way.

7 questions. Free, with results on screen and no email needed.

7 questions · Results on screen

Scale planner

Common answers are preselected. Change any that don't match.

Expected users

A rough peak is fine. If you don't know, estimate high.

Backend shape
Main database
Cache
Queue
Where it runs

About this planner

  • Will your backend handle 100k users?

    The honest answer is that nobody knows until it's load tested. Anyone who guarantees a number without load testing your system against your data is guessing. What we can say, from your answers, is where the pressure lands first.

  • Why the first bottleneck is rarely the CPU

    Connection pools run out long before the CPU is busy. Without a cache, every read reaches the database, which is the most common first bottleneck. Without a queue, slow work runs inside the request, so a traffic spike becomes an outage instead of a slower response.

  • How the planner reads your answers

    • No cache marks the cache as a likely bottleneck; an in-process cache is one to watch.
    • No queue marks the queue as likely.
    • At 1,000 requests per second or more, the API layer is likely to bind first; from 200, it's one to watch.
    • At 100k users or more, with a database chosen, write contention is likely.
    • A single VM is likely to be a limit, because it can't scale out.
    • Microservices below 100k users, and serverless at 500 requests per second or more, are flagged to watch.
    • The first bottleneck shown is the first "likely" item, checked in this order: API layer, cache, queue, database, deployment.

  • What to do with the result

    Fix the first likely bottleneck before the rest; the next one only shows once it's gone. Then add the measurements in "Measure these first", so the next decision is based on your numbers, not ours.

  • What it can't tell you

    It doesn't see your code, your queries or your data, so it can't give you a capacity number. Take the plan to a load test, or to a call with an engineer.

Related