Skip to main contentSkip to user menuSkip to navigation
Interactive design lab

System Design Calculator

What is system sizing?

System sizing turns product behavior into a capacity envelope: the traffic each tier must serve, the reserve it keeps, the data it stores, and the failures it can absorb.

Step 1

Model

Model user demand and cache behavior, then provision benchmarked application and database capacity, headroom, failure domains, and storage replication.

Step 2

Observe

Trace requests from users to the data tier, compare demand with safe capacity, and identify the first bottleneck instead of relying on one headline server count.

Step 3

Challenge

Create a healthy baseline, then inject a launch surge, cache outage, zone loss, slow data tier, or retry storm and recover the design by changing the relevant assumption.

Architecture sizing workbench

Turn product demand into a defensible capacity plan

Model the user peak, trace amplification through the request path, then test whether the provisioned architecture keeps its operating reserve under pressure.

Evaluated outcome

Design has reserve

Pressure test

Apply a failure or demand shock

Scenarios alter the evaluated request path without changing your saved assumptions.

Incoming peak

3.7K RPS

80M requests/day before retries

Database demand

1.2K RPS

80% effective read-cache hit rate

Tightest margin

+704.8 RPS

Data tier is the limiting tier

Modeled monthly cost

$8.3K

31.3 TB physical storage

Live request path

Follow demand as each tier transforms it

The selected scenario changes attempts, available nodes, or measured throughput. Node rings identify the tiers closest to or beyond their safe envelope.

Active scenario

Expected peak · Healthy day

Demand

Users and clients

3.7K RPS

533 Mbps peak response bandwidth

3.7K attempts

Demand shaping

Cache and request layer

80% hits

2.5K reads stop before the database

3.7K app RPS
Within envelope

Compute

Application fleet

10/10 live

59% of safe capacity

1.2K origin RPS
Within envelope

State

Database tier

3/3 live

63% of safe capacity

Capacity envelope

Compare demand with safe operating capacity

Safe capacity subtracts your headroom before utilization is evaluated. A tier can be below its benchmark maximum and still violate the operating policy.

Application fleet

3.7K demanded / 6.3K safe RPS

59%

Database tier

1.2K demanded / 1.9K safe RPS

63%

Average load

925.9 RPS

4x peak ratio before scenario pressure

Peak bandwidth

533 Mbps

18 KB average response payload

Logical retained data

8.4 TB

365 days at 2 KB per write

Physical retained data

31.3 TB

3x replication plus 25% index overhead

Architecture verdict

Design has reserve

Demand follows the workload assumptions and every failure domain is available.

First constraint

Data tier

  • 30% reserve remains outside the safe-capacity line.
  • Data tier is the tighter tier, so measure it first as demand changes.
Application capacity equation

10 live instances × 900 tested RPS × 70% operating share

= 6.3K safe RPS

Database capacity equation

3 live nodes × 900 tested RPS × 70% operating share

= 1.9K safe RPS

No quiz questions available
Could not load questions file
Spotted an issue or have a better explanation? This page is open source.Edit on GitHub·Suggest an improvement