CalcEngine All Calculators

QPS Calculator

API & Backend

Enter your total request count and time window to calculate average and peak QPS instantly. Built for backend engineers sizing APIs, rate limits, and infrastructure.

Last updated: April 2026

This calculator is designed for real-world usage based on typical engineering scenarios and publicly available documentation.

A QPS calculator converts raw request counts into the queries-per-second rate your system must sustain, which is the metric that actually drives infrastructure sizing decisions. Knowing your average QPS tells you how much steady-state capacity you need; knowing your peak QPS tells you how much headroom to build in before you start dropping requests. Backend engineers use QPS to set rate limits, size connection pools, choose instance counts, and negotiate SLAs. SREs use it to decide when to trigger autoscaling and what runbook thresholds to set. If you're planning a new service, forecasting traffic growth, or post-morteming an incident, the first question is always "what was the QPS at the time?" The peak multiplier accounts for the fact that traffic is never flat. A service handling 1M requests/day on average might see 3–5× that rate during a flash sale, a viral moment, or a scheduled batch job. Industry convention is to provision for 2–3× average QPS for consumer APIs and 4–5× for event-driven or batch-adjacent workloads. This calculator works for any unit — HTTP requests, database queries, message-queue events, gRPC calls. The formula is the same: divide total events by the observation window in seconds.

How to Calculate QPS (Queries Per Second)

QPS — how it works diagram

1. Count the total number of requests (or queries, events, or messages) in a given period. 2. Convert your observation window to seconds — 1 hour = 3,600 s, 1 day = 86,400 s. 3. Divide total requests by seconds to get Average QPS. 4. Multiply Average QPS by your Peak Multiplier (typically 2–5×) to get Peak QPS. 5. Use Peak QPS to size your servers, connection pools, and rate-limit thresholds.

Formula

Average QPS = Total Requests ÷ Time Window (seconds)
Peak QPS    = Average QPS × Peak Multiplier

Total Requests  — number of requests (HTTP, DB queries, events, etc.) in the window
Time Window     — observation period in seconds (86400 = 1 day, 3600 = 1 hour)
Peak Multiplier — ratio of peak traffic to average (commonly 2–5×)

Example QPS Calculations

Example 1 — REST API with 1M daily requests

Total Requests: 1,000,000
Time Window:    86,400 seconds (1 day)
Average QPS:    1,000,000 ÷ 86,400  =  11.57 QPS
Peak Multiplier: 3×
Peak QPS:       11.57 × 3  =  34.72 QPS
→ Provision for ~35 QPS; each 2-vCPU instance handling 50 QPS gives you 1 instance + headroom.

Example 2 — High-traffic e-commerce checkout during sale (10M requests/hour)

Total Requests: 10,000,000
Time Window:    3,600 seconds (1 hour)
Average QPS:    10,000,000 ÷ 3,600  =  2,778 QPS
Peak Multiplier: 5× (flash-sale spike)
Peak QPS:       2,778 × 5  =  13,889 QPS
→ Need infrastructure able to sustain ~14k QPS; consider horizontal autoscaling triggered at 70% capacity.

Example 3 — Database read replica sizing (500k queries over 10 minutes)

Total Requests: 500,000
Time Window:    600 seconds (10 minutes)
Average QPS:    500,000 ÷ 600  =  833 QPS
Peak Multiplier: 2×
Peak QPS:       833 × 2  =  1,667 QPS
→ A single read replica rated at 2,000 QPS covers peak with 17% spare capacity — add a second replica for HA.

Tips for QPS Capacity Planning

Notes

Frequently Asked Questions

What is QPS and why does it matter? +
QPS stands for Queries Per Second — the rate at which a system processes requests, queries, or events. It's the standard unit for measuring API throughput, database load, and service capacity. Engineers use QPS to size infrastructure, set rate limits, plan autoscaling thresholds, and write SLOs. Exceeding your system's sustainable QPS causes latency spikes, connection exhaustion, and dropped requests.
What is a good peak multiplier to use? +
For most consumer-facing REST APIs, 3× average QPS is a reasonable starting point. Use 5× or higher for event-driven workloads, marketing-heavy products with flash sales, or services that receive retry storms. Internal microservices with predictable callers can often use 2×. The right number comes from your traffic percentile data — compare your p99 one-minute rate against the daily average.
What is the difference between QPS, RPS, and TPS? +
QPS (queries per second), RPS (requests per second), and TPS (transactions per second) all measure throughput rate and use the same formula. The terms differ by context: QPS is common for databases and search systems, RPS for HTTP APIs, and TPS for transactional databases or payment systems. In practice they are interchangeable in calculations — use the one that matches your monitoring tool's terminology.
How do I find my actual QPS from logs or metrics? +
In most APM tools, look for the "request rate" or "throughput" metric, which is already expressed as per-second. From raw logs, count requests in a fixed window and divide by window seconds. In SQL: COUNT(*) / TIMESTAMPDIFF(SECOND, MIN(ts), MAX(ts)). In PromQL: rate(http_requests_total[5m]) gives you a 5-minute rolling average QPS. Always sample a representative weekday, not just off-peak windows.
How many servers do I need to handle a given QPS? +
Divide your Peak QPS by the per-instance sustainable throughput — benchmark this under realistic load, not synthetic no-op tests. Add 20–30% headroom for GC pauses, health checks, and gradual rollouts. For example, if peak is 3,000 QPS and each instance handles 400 QPS, you need 3,000 ÷ 400 = 7.5 → 8 instances, then add 2 for headroom = 10 instances minimum. Use the Cache Hit Rate Calculator to reduce the QPS that actually reaches your backend.