Pick a depth. Each prompt opens in your AI pre-loaded with the lesson. Click a row to preview the prompt.
Nobody serves a flat million. Traffic has a shape, and for a single-country consumer product that shape is severe — an Indian consumer app might do a million a second at 9 pm and thirty thousand at 4 am, a peak-to-trough ratio above thirty and a peak-to-mean ratio around two. Every number in the previous tasks silently assumed one of these two, and picking the wrong one is a two-to-four-fold error in either direction. Fleet size follows peak, because peak is when you fail. Bandwidth cost follows mean, because you pay by the byte. Confuse them and you either over-buy machines by a factor of two or under-budget bandwidth by the same factor. There is a second consequence that catches people politically rather than technically: once you provision for peak, add a utilisation target, and add enough headroom to survive losing one availability zone of three, your fleet averages under twenty percent utilisation. That looks like waste on a finance dashboard, and it is not — it is the price of peak plus a failure domain. Being able to show the arithmetic is the difference between defending that fleet and having it cut two weeks before a festival sale. And autoscaling only recovers part of it, because it helps exactly when your scale-out time is shorter than your ramp: a four-hour evening ramp, comfortably; a flash sale that does ten times in sixty seconds, not at all.
Take an hourly shape typical of a single-country consumer app, normalise it so the busiest hour is 1.0, and read off the three numbers that matter: peak, mean, and the capacity you are actually forced to own. Then work out whether autoscaling can chase the ramp.
# diurnal.py — peak, mean, and what you are actually forced to buy
PEAK_RPS = 1_000_000
# 24 hourly values, relative to the peak hour, for a single-country consumer
# app on IST. Replace these with your own week of data.
shape = [.10, .06, .04, .03, .04, .07, .14, .28,
.44, .56, .62, .66, .70, .66, .62, .60,
.64, .74, .86, .95, 1.00, .94, .66, .30]
hourly = [PEAK_RPS * s for s in shape]
peak, mean, trough = max(hourly), sum(hourly) / len(hourly), min(hourly)
print(f"peak {peak:>9,.0f} rps")
print(f"mean {mean:>9,.0f} rps")
print(f"trough {trough:>9,.0f} rps")
print(f"peak:mean {peak / mean:.2f} peak:trough {peak / trough:.0f}")
# peak 1,000,000 rps
# mean 487,917 rps
# trough 30,000 rps
# peak:mean 2.05 peak:trough 33
# What you must own, versus what you use on average.
TARGET_UTIL, FAILURE_HEADROOM = 0.60, 1.5 # survive losing 1 of 3 zones
capacity = peak / TARGET_UTIL * FAILURE_HEADROOM
print(f"capacity you must buy: {capacity:,.0f} rps "
f"({capacity / mean:.1f}x your mean load)")
print(f"average utilisation of that fleet: {mean / capacity:.0%}")
# capacity you must buy: 2,500,000 rps (5.1x your mean load)
# average utilisation of that fleet: 20%
# Can autoscaling recover any of it? Only if scale-out beats the ramp.
ramp_from, ramp_to, ramp_hours = .30, 1.00, 4
per_30min = (ramp_to / ramp_from) ** (1 / (ramp_hours * 2)) - 1
print(f"evening ramp: +{per_30min:.0%} every 30 minutes")
# evening ramp: +16% every 30 minutesshape with 24 numbers from your own week of traffic, using the awk one-liner above and normalising so the busiest hour is 1.0. Read off your real peak-to-mean ratio and compare it against the 2.05 in the example.FAILURE_HEADROOM to 1.0 and note that the fleet shrinks by a third. Then say out loud what happens the next time one availability zone goes away at 9 pm on a Friday.utilisation_at_mean. Record that number in both rupees and dollars — it is what owning peak capacity costs you every month, and someone will eventually ask.