Understanding the Difference Between TPS, QPS, and Concurrency in High‑Throughput Systems

TPS (Transactions Per Second)

TPS measures the number of successful transactions a system completes per second. A transaction typically involves multiple steps or database changes and is treated as an atomic unit that must be fully committed. For example, an order process that includes the order API call, inventory deduction, and order‑record insertion counts as one TPS when it completes successfully.

QPS (Queries Per Second)

QPS originally gauges the rate of query‑type requests processed per second, such as HTTP requests, cache lookups, or database reads. For instance, handling 10,000 HTTP requests in one second yields a QPS of 10,000. QPS emphasizes the count of individual request operations, especially in stateless, read‑heavy scenarios.

→ QPS = 10,000

Concurrency (Concurrent Requests)

Concurrency refers to the number of active requests or connections the system is handling at a single point in time. If 500 requests are in progress simultaneously, the concurrency level is 500. Concurrency impacts resource consumption (threads, connections, memory) and response latency but does not directly represent processing speed.

Relationship Among TPS, QPS, and Concurrency

Concurrency determines how many requests can be processed in parallel, which influences the maximum number of transactions or queries that can be completed per second (TPS/QPS). TPS/QPS measure the throughput over time, while concurrency reflects the instantaneous load. In many load‑testing scenarios, QPS and TPS may appear equivalent, but they differ conceptually: a single user flow (e.g., a page visit or order process) counts as one TPS, whereas all underlying backend calls generated by that flow contribute to the total QPS.