Scalability & Capacity Planning Questions

Framing

Monthly active users (MAU) is not the number that drives capacity, peak concurrent load is. The first job is translating MAU into an expected peak concurrency, and that ratio usually isn't constant as the user base grows: early adopters tend to be more engaged than the mainstream users who join later, so the concurrency-to-MAU ratio often drifts down as the base grows tenfold.

Staged ramp plan

I'd break the 100K to 1M MAU journey into checkpoints rather than one big jump, say roughly monthly: 100K (baseline), 400K, 700K, 1M. For each checkpoint I'd estimate peak concurrency using an engagement ratio that declines slightly as the base grows, for example 2.0% at 100K, 1.8% at 400K, 1.6% at 700K, and 1.5% at 1M:

• 100K MAU x 2.0% = 2,000 peak concurrent
• 400K MAU x 1.8% = 7,200 peak concurrent
• 700K MAU x 1.6% = 11,200 peak concurrent
• 1,000K MAU x 1.5% = 15,000 peak concurrent

That's the useful insight: MAU grows 10x but concurrent load only grows about 7.5x, because engagement dilutes as the base scales. (The opposite can also happen: a social feed where growth increases cross-user reads can make load grow faster than MAU, so I'd validate the ratio against real engagement data rather than assume it always falls.)

What I'd test before each stage

Before opening the gate to the next checkpoint, I'd load test at roughly 1.3x that stage's projected peak, using the real feature mix, and I'd specifically test the dependency that looked weakest at the prior stage rather than re-testing everything uniformly. That way each stage gate is validated ahead of where traffic will actually be, not behind it.

Managing cost so it doesn't spike ahead of growth

The failure mode to avoid is provisioning for the full 1M-MAU ceiling on day one and paying for months of unused capacity. Instead, I'd buy capacity in increments tied to each stage gate, short reservations or committed-use terms (a discount from a cloud provider in exchange for committing to a set spend or usage level over a period, similar to a reserved instance) scoped to the checkpoint rather than the full 3-month horizon, and only commit the next increment once that stage's load test confirms the forecast is holding. That keeps spend roughly tracking actual usage instead of a worst-case guess made three months early.

Translating the burst requirement into a plan

Start from a tested number, not a guess: say load testing shows the current fleet's ceiling is 40,000 requests per second (RPS) before p99 latency (the slowest 1% of requests) breaches the service level agreement (SLA). The target is 100,000 RPS, plus a buffer for forecast and measurement error, say 20%, giving a target ceiling of about 120,000 RPS, three times the current tested ceiling.

Metrics and thresholds as evidence

I'd bring the load-test result itself ("today's tested ceiling is 40,000 RPS before SLA breach"), the cost-per-throughput-unit (cost per 1,000 RPS of capacity), and the consequence of not funding it: above 40,000 RPS today, the service doesn't degrade gracefully, it fails outright, because of a specific downstream constraint (for example, connection pool exhaustion). Grounding the ask in a tested number and a specific failure mode makes it evidence rather than an opinion.

Presenting the trade-off to finance

I'd translate infrastructure units into business terms rather than lead with RPS:

• Reframe the ceiling as a business-legible number: "up to X peak concurrent customers" or "X peak orders per minute" instead of "120,000 RPS."
• Reframe cost per unit of the ask, not just the total: "$Y per month buys headroom for Z% more peak customers," rather than a raw infrastructure dollar figure with no anchor.
• Present tiers instead of one fixed number, so finance chooses the risk level rather than being asked to approve or reject a single figure.

Worked example

Current infra costs $50K/month at the 40,000 RPS ceiling, a unit rate of about $1.25 per RPS of capacity per month. Scaling to the 120,000 RPS target is roughly 3x capacity, so at that same linear unit rate that's about $150K/month, a $100K/month increase. I'd present it as three tiers built on that same rate: Tier A, minimal (80,000 RPS ceiling, about $100K/month total, a $50K/month increase, still short of the 100,000 RPS target and risks falling over on the largest expected burst), Tier B, recommended (120,000 RPS, about $150K/month total, a $100K/month increase, covers the full target with buffer), and Tier C, max safety (150,000 RPS, about $188K/month total, a $138K/month increase). Each tier is tied to a specific quantified cost and residual risk, so finance is choosing a risk level with eyes open, not just approving a single number.