No. Bursts, service time, headroom, and failures all affect capacity.

Functional requirements name operations and users. Quality requirements specify latency, throughput, availability, durability, consistency, privacy, and recovery. Distinguish an SLI measurement from an SLO target and an SLA contractual promise. Define scope: for example, text notes only, one region initially, authenticated users, read-your-writes after save. Capacity estimates are hypotheses to load-test, not precise predictions. A design answer should identify the workload and hardest invariant before naming a database or queue.

What the function promises: The runnable model converts daily request count and an explicitly assumed peak multiplier into average and peak requests per second. It is arithmetic, not a measured capacity guarantee.

def traffic_estimate(daily_requests, peak_multiplier):
    if daily_requests < 0 or peak_multiplier < 1:
        raise ValueError("Invalid workload assumptions")
    average = daily_requests / 86400
    return {"average_rps": average, "assumed_peak_rps": average * peak_multiplier}

estimate = traffic_estimate(864000, 8)
assert estimate == {"average_rps": 10, "assumed_peak_rps": 80}
assert traffic_estimate(0, 1)["average_rps"] == 0

Work and storage: Constant-sized arithmetic. The value is making assumptions visible and revisable.

When to recognize it: Ten thousand requests per day is an average, not a peak. A short burst can dominate the capacity we actually need.

Check before applying it: Architecture follows a defined workload and failure contract, not a generic shopping list of technologies.

No. Fan-out, ranking, hot authors, moderation, and freshness expectations change the workload. Re-estimate and identify which previously adequate boundaries become bottlenecks.