Throughput Estimator
Back-of-the-envelope capacity planning: turn daily or monthly active users into average and peak requests per second, bandwidth, monthly transfer, concurrent in-flight requests (Little's Law) and the number of servers or pods you need with headroom. Includes a quick RPS ↔ requests per day and month converter.
Private by design: anything you enter is processed in your browser only. It is never uploaded to or logged on our servers. Traffic numbers and capacity assumptions never leave this page.
Traffic assumptions
Busiest second ÷ daily average; 2–5 is typical.
1 KB = 1,000 bytes (decimal).
Headroom 30% means instances run at no more than 70% of capacity at peak.
Estimates
Requests
Bandwidth (egress, response bodies only)
Concurrency & capacity
Quick converter: RPS ↔ requests per day / month
Type in any box; the others update. Month = 30 days, year = 365 days, constant rate assumed.
About throughput and capacity estimation
Capacity planning starts with a simple chain: users × requests per user gives requests per day, and dividing by 86,400 seconds gives the average requests per second (RPS). Traffic is never flat, so the average is multiplied by a peak-to-average factor (often 2–5 for consumer apps with a daily cycle, higher for launches, sales or push notifications) to get the peak load you must actually survive. The numbers are rough by design; their value is in showing which order of magnitude you are in before you choose an architecture or run a load test.
Bandwidth follows from RPS × response size. This tool uses decimal SI units throughout: 1 KB = 1,000 bytes, 1 GB = 10⁹ bytes, 1 TB = 10¹² bytes, and network speed in megabits per second (1 Mbps = 10⁶ bits/s, so multiply bytes by 8). Cloud providers bill egress per GB, and some of them mean GiB (2³⁰ bytes, about 7% more), so check the definition before turning TB/month into cost. Only response bodies are counted; headers, TLS and TCP overhead typically add a few hundred bytes per request.
Little's Law (L = λ × W) links throughput and latency: the average number of requests in flight equals the arrival rate times the time each one spends in the system. At 1,000 RPS and 200 ms response time there are 200 requests in progress at any moment. That is what consumes worker processes, threads, database connections and memory, which is why a latency regression can exhaust a connection pool without any growth in traffic. Inverting it gives per-instance capacity: an instance with 50 workers and 200 ms responses can serve at most 50 ÷ 0.2 = 250 RPS.
The instance count divides peak RPS by per-instance capacity reduced by your headroom, then rounds up. Headroom covers uneven load balancing, garbage-collection pauses, a zone or node failing and the time autoscaling needs to react. Validate the per-instance number with a real load test, and compare the result against your availability goals in the SLA & uptime calculator. To measure the real peak factor and response sizes from production traffic, paste an access log into the log analyzer.
Reference Guide
Formulas used:
| Output | Formula |
|---|---|
| DAU from MAU | MAU × (DAU/MAU ratio) |
| Requests per day | DAU × requests per user per day |
| Average RPS | requests per day ÷ 86,400 |
| Peak RPS | average RPS × peak factor |
| Requests per month | requests per day × 30 |
| Bandwidth (Mbps) | RPS × size in bytes × 8 ÷ 1,000,000 |
| Transfer per day (GB) | requests per day × size in bytes ÷ 10⁹ |
| Concurrent requests (Little's Law) | L = λ × W = RPS × response time in seconds |
| Capacity per instance | workers ÷ response time (s), or the measured max RPS |
| Instances needed | ceil(peak RPS ÷ (capacity × (1 − headroom))) |
Back-of-the-envelope numbers:
| Quantity | Value |
|---|---|
| Seconds per hour | 3,600 |
| Seconds per day | 86,400 (≈ 10⁵) |
| Seconds per week | 604,800 |
| Seconds per 30-day month | 2,592,000 (≈ 2.6 million) |
| Seconds per average month (30.4375 days) | 2,629,800 |
| Seconds per year (365 days) | 31,536,000 (≈ 3.15 × 10⁷) |
| 1 RPS sustained | 86,400 per day ≈ 2.6 million per month |
| 1 million requests per day | ≈ 11.6 RPS average |
| 1 billion requests per month (30 days) | ≈ 386 RPS average |
| 1 Gbps | 125 MB/s ≈ 10.8 TB per day |
| 1 MB/s | 8 Mbps ≈ 86.4 GB per day |
Worked example (the sample values): 1,000,000 DAU × 50 requests = 50 million requests per day. 50,000,000 ÷ 86,400 = 578.7 RPS on average, × 3 = 1,736 RPS at peak. With 20 KB responses that is 578.7 × 20,000 × 8 = 92.6 Mbps on average (278 Mbps at peak) and 1,000 GB = 1 TB per day, 30 TB per month. At 200 ms, Little's Law gives 1,736 × 0.2 = 347 requests in flight at peak. An instance with 50 workers handles 50 ÷ 0.2 = 250 RPS; keeping 30% headroom leaves 175 RPS, so you need ceil(1,736 ÷ 175) = 10 instances.
Example input
DAU 1,000,000 · 50 requests/user/day · peak factor 3 Response time 200 ms · response size 20 KB 50 workers per instance · 30% headroom
This sample loads automatically when you open the tool. Use Load Sample to bring it back.
Frequently Asked Questions
Divide by 86,400 seconds per day for the average, then multiply by a peak factor (often 2 to 10) because traffic is not spread evenly across the day.
Little's Law says the average number of requests in flight equals the arrival rate times the average time each request takes (L = λ × W). It tells you how much concurrency your servers must handle.
No. They are back-of-the-envelope numbers for capacity planning. Confirm them with load tests against your real application.
Related Tools
All DevOps Tools →Conventional Commit & Changelog Generator
Write Conventional Commits messages with a guided builder an...
Web Server Config Generator
Generate Nginx server blocks and Apache .htaccess rules for...
CSP Header Builder
Build a Content-Security-Policy header directive by directiv...
Subnet Calculator
Calculate IPv4 subnets from CIDR notation: network and broad...
OpenAPI Validator & Viewer
Validate OpenAPI 3.x and Swagger 2.0 specs in YAML or JSON,...
HAR File Viewer & Analyzer
Open HAR files from browser DevTools to inspect every reques...