System Sizing & Capacity Planning

Model server fleets, bandwidth, storage, and SLA budgets with CalcMark.

How many servers do you need? How much bandwidth? What’s the storage budget for the next quarter? These are napkin-math problems — you need rough answers fast, not exact answers slow.

CalcMark is built for this. Write your assumptions in plain text, let the math flow, and change any number to see the cascade.

Try it now: Open the System Sizing example in Lark or run cm remote system-sizing in the editor.

Key Features for This Domain #

FeatureWhat It DoesReference
Rates (100 MB/s, $50/hour)Model throughput, cost rates, request ratesRates
at...per capacity syntax“10 TB at 2 TB per disk” → 5 disksCapacity Planning
as napkinRound to 2 sig figs for back-of-envelope estimatesNapkin Math
Multiplier suffixes (10K, 1.5M)Compact notation for large numbersMultipliers
over keywordAccumulate a rate over time: 100 MB/s over 1 dayRates
Network functions (rtt, throughput)Model latency, bandwidth, transfer timeNetwork Functions
Storage functions (read, seek)Model disk I/O by device typeStorage Functions

Walkthrough: Sizing a Web Service #

Step 1: Traffic Assumptions #

Start with what you know — expected requests per second and growth rate:

peak_rps = 10K/s
avg_rps = peak_rps * 0.4
daily_requests = avg_rps over 1 day
growth_rate = 25%
Results
peak_rps = 10K/s→10K/s
avg_rps = peak_rps * 0.4→4K/s
daily_requests = avg_rps over 1 day→345.6M
growth_rate = 25%→25%

daily_requests uses over to accumulate the average rate across a full day. growth_rate is a percentage — CalcMark tracks the type.

Step 2: Compute Capacity #

Each server handles a known number of requests. How many servers for the peak?

capacity_per_server = 2K
servers_needed = peak_rps at capacity_per_server
Results
capacity_per_server = 2K→2K

The at...per syntax divides and rounds up — you can’t run half a server.

Step 3: Storage Budget #

Estimate storage from request volume and payload size:

avg_payload = 4 KB
daily_storage = daily_requests * avg_payload as napkin
monthly_storage = daily_storage * 30 as napkin
Results
avg_payload = 4 KB→4 KB
daily_storage = daily_requests * avg_payload as napkin→~1.3 TB
monthly_storage = daily_storage * 30 as napkin→~39 TB

as napkin rounds to 2 significant figures — perfect for planning where ~14 GB is more useful than 13.8240 GB.

Step 4: Network I/O #

Use the built-in throughput and transfer_time functions:

link_speed = 10 gigabits
burst_transfer = transfer_time 50 GB at link_speed
Results
link_speed = 10 gigabits→10 gigabits