Menu

Earn Premium with Referrals

Invite your friends and earn Premium rewards through our referral program.

See how it works and start inviting friends.

QPS and TPS
HLD

QPS and TPS

Queries and transactions per second — definitions, the relationship between them, and how each is estimated or measured.

Definitions That Actually Differ

 QPS (queries/requests per second)
    count of request-level operations served
    one API call = 1, regardless of internal work

 TPS (transactions per second)
    count of business transactions
    one transaction may span MANY queries internally

 RPS: same shape as QPS; used for HTTP traffic

The gap between them is where estimates go wrong:

 ONE checkout transaction (1 TPS) =
   validate cart        (1 query)
   reserve inventory    (2 queries)
   create order         (2 queries)
   authorize payment    (1 external call + writes)
 ────────────────────────────────────────
 ≈ 6+ backend queries → 1 TPS ≈ 6–10 QPS at the data layer
 
 sizing the DATABASE on user-facing TPS underestimates 5–10x

Estimating Both (RideShare running numbers)

 USER-FACING QPS:
   140M rider requests/day ÷ 10⁵ s     ≈ 1,400 rps average
   × 2.5 peak                          ≈ 3,500 rps peak

 TRANSACTIONAL TPS:
   20M trips/day ÷ 10⁵                 ≈ 200 TPS average
   × 2.5                               ≈ 500 TPS peak (matches+completions)

 DATA-LAYER QPS (what Postgres actually sees):
   trip writes: ~5 queries per trip    ≈ 1,000 qps write-side peak
   history reads: cache misses only    ≈ few hundred qps after caching

Three numbers, three audiences: rps for capacity of app tier, TPS for business metrics, data-layer QPS for database sizing. Conflating them mis-sizes everything.

Measured vs Estimated

SourceWhat it givesCaveats
Load testsPer-node service ratesSynthetic patterns miss production skew
Production metricsTruth per endpointOnly exists after launch
Back-of-envelopeDesign-stage targetsAssumptions must be stated

Lifecycle honesty: design starts with envelope math, load tests calibrate per-node ceilings, production replaces both within months.

Amplification Factors to Watch

Measured client QPS understates system work when:

  • Fan-out reads: one feed view triggers N internal lookups.
  • Retries: a 1% timeout rate with retries adds meaningful duplicate load.
  • Health checks: constant background QPS against every node.
  • Cache misses cascading: miss storms multiply origin traffic exactly when it hurts.

Each factor argues for measuring at the layer being sized, not at the edge.

Interview Framing

State which layer every number refers to (“3,500 rps at the edge, roughly 1,000 write-qps hitting the primary”). When an interviewer doubles traffic, strong candidates re-derive per layer rather than doubling one headline — because caches, pools, and fan-outs scale differently than user requests.

My Private Notes

Notes are auto-saved locally to this device.