Pick a depth. Each prompt opens in your AI pre-loaded with the lesson. Click a row to preview the prompt.
Capacity arithmetic stops being academic the moment it becomes a number on a purchase order, and this is where most napkin estimates go badly wrong in a specific and predictable direction. People compute the servers, feel proud of the answer, and never compute the bandwidth — and at a million requests a second with ordinary two-kilobyte JSON responses, the bytes leaving your data centre cost roughly nine times the machines producing them. That is not a rounding error you can absorb; it is the difference between a service that is viable and one that is not, and it inverts what you should optimise. Halving your response body — dropping fields nobody reads, turning on compression, paginating properly — is worth more than any amount of code tuning, because it halves the largest line on the bill while barely touching the second largest. There is a second trap on the compute side. The napkin ceiling for a box is always far higher than what the box does, because garbage collection, lock contention, allocator behaviour, softirq and the headroom you must leave for the tail all take their cut. Applying an honest derate factor, measured on your own stack rather than assumed, is the difference between a fleet that survives its first evening peak and a fleet that pages you during it.
Start from the CPU-per-request figure of the previous task, turn it into a per-box rate, apply an honest derate, add failure headroom, and then price both compute and egress in rupees and dollars. Watch which line dominates.
# fleet.py — boxes and money at a million requests a second
import math
RPS = 1_000_000
CPU_US = 79 # measured, from the previous task
UTIL = 0.60 # utilisation target
VCPU_PER_BOX = 32
USD_INR = 66.5 # this ratio moves; look up today's before you quote
# 1. The napkin ceiling.
per_box_rps = VCPU_PER_BOX * UTIL / (CPU_US / 1e6)
print(f"arithmetic ceiling: {per_box_rps:>10,.0f} rps/box")
# arithmetic ceiling: 243,038 rps/box
# 2. The haircut. Real services land well under the arithmetic because of
# garbage collection, lock contention, allocator behaviour, softirq, and
# the fact that you must leave headroom for the tail. MEASURE yours.
DERATE = 0.30
real_rps = per_box_rps * DERATE
print(f"measured (derate {DERATE}): {real_rps:>10,.0f} rps/box")
# measured (derate 0.3): 72,911 rps/box
# 3. Failure headroom: survive losing one availability zone out of three.
AZ_HEADROOM = 1.5
boxes = math.ceil(RPS / real_rps * AZ_HEADROOM)
print(f"fleet: {boxes} boxes")
# fleet: 21 boxes
# 4. Compute.
BOX_USD_HR = 1.36 # a 32-vCPU compute instance, on-demand, US region
compute_usd = boxes * BOX_USD_HR * 730
print(f"compute: ${compute_usd:>10,.0f}/mo = Rs {compute_usd * USD_INR:>12,.0f}/mo")
# compute: $ 20,849/mo = Rs 1,386,445/mo
# 5. Egress. Note the peak-to-mean correction — you size the fleet on peak
# but you pay for bandwidth on the mean.
RESP_BYTES = 2_048
PEAK_TO_MEAN = 2.5
mean_rps = RPS / PEAK_TO_MEAN
gb_month = mean_rps * RESP_BYTES * 2.592e6 / 1e9
EGRESS_USD_GB = 0.085 # public-cloud list rate past the first tiers
egress_usd = gb_month * EGRESS_USD_GB
print(f"egress: {gb_month / 1e6:.2f} PB/mo")
print(f"egress: ${egress_usd:>10,.0f}/mo = Rs {egress_usd * USD_INR:>12,.0f}/mo")
# egress: 2.12 PB/mo
# egress: $ 180,486/mo = Rs 12,002,329/mo
print(f"\negress is {egress_usd / compute_usd:.1f}x compute")
# egress is 8.7x computeDERATE to 1.0 and read the fleet size: six boxes. That is the number the napkin gives you and the number that pages you at 9 pm. Then measure your own derate on one box with a constant-rate load test and put the real value in.RESP_BYTES from 2048 to 1024 and read the egress line again. Write down the monthly saving in both currencies, then go and check whether your JSON genuinely needs every field it currently sends.EGRESS_USD_GB with your own contracted rate or your CDN's, and BOX_USD_HR with the on-demand price of the instance family you actually run. Recompute the egress-to-compute ratio: if it is above 3, your next week of optimisation work belongs in the response body, not in the request path.PEAK_TO_MEAN = 1.0, which is the naive peak-rate extrapolation almost everyone does first, and note that it overstates the bandwidth bill by 2.5x. Peak sizes your fleet; mean sizes your bandwidth. They are different questions and they take different inputs.