Understanding QPS vs. TPS: Measuring High Concurrency in Backend Systems

High Concurrency

High concurrency describes a situation where a large number of requests arrive within a short time window and the system can still respond within an acceptable latency. A classic example is Alibaba’s Double‑11 “seconds‑kill” scenario, which processes hundreds of thousands of orders per second.

Key Metric: QPS (Queries Per Second)

QPS measures how many queries a system can receive or process each second. It is calculated as: QPS = total_queries / time_interval_seconds Example: processing 5,000 queries in 10 seconds yields a QPS of 500.

Typical single‑node capacities (approximate):

Nginx: > 50 k QPS

Redis: > 100 k QPS

MySQL: 3 k – 10 k QPS (depends on indexing and I/O)

QPS is most useful for read‑intensive workloads such as search engines, static content delivery, or API gateways.

Key Metric: TPS (Transactions Per Second)

TPS counts completed business transactions, i.e., the full sequence from start to successful commit. It reflects the system’s ability to finish complex operations that involve writes, consistency guarantees, or distributed transactions.

Typical scenarios where TPS is the primary throughput indicator include e‑commerce order processing, financial settlement, and any workflow that must guarantee atomicity.

Difference Between QPS and TPS

A single business transaction may consist of multiple queries. For example, an order placement flow typically involves:

Query inventory (1 QPS)

Decrement stock (1 QPS)

Create order record (1 QPS)

These three queries count as three QPS but only one TPS in business statistics. Pure information‑serving services (e.g., news list) may have QPS ≈ TPS, whereas complex transactional services rely on TPS as the key performance indicator.