RPS and QPS

RPS describes incoming request intensity

RPS means requests per second. It is one of the most useful quantities for quick load estimation because it converts large daily totals into the rate at which the system actually receives work.

If a service processes 8.64 million requests per day and they are distributed evenly, the average intensity is about 100 RPS.

8,640,000 requests/day ÷ 86,400 s/day = 100 RPS

This is an average. It is useful as a starting point, but it does not mean that exactly one hundred requests arrive every second throughout the day. We will cover uneven load on the next page.

Separate different operation types

A single total RPS can hide important structure. Many systems have far more reads than writes, and these operations have different costs. That is why it is useful to estimate them separately.

read_RPS  = 4,000
write_RPS =   200
total_RPS = 4,200

This separation immediately reveals the workload profile. For example, optimizing the read path may have a much larger effect if there are twenty reads for every write.

QPS is similar, but context matters

QPS means queries per second. The term is often used for queries to a database, search engine, or another component that processes query-like operations. In practice, RPS and QPS are sometimes used almost interchangeably, so always clarify what is being counted.

One incoming HTTP request does not have to become one database query. It may not access the database at all, or it may execute several operations.

1 API request → 3 database queries
2,000 API RPS → about 6,000 DB QPS

That is why you cannot automatically apply the external API RPS to every internal component. For each important part of the system, you need its own multiplier: how much work it receives from one user operation.

Start from user actions

If the prompt gives only a user count, first estimate action frequency. For example, 5 million active users opening 10 pages per day on average produce 50 million page views per day, or roughly 580 average RPS.

The estimate can then be refined separately for reads, writes, and internal calls. The key is to preserve the chain from a product action to technical load instead of inventing an RPS value without a basis.