Estimating QPS

The Core Chain

Every QPS estimate is the same three-step multiplication:

 DAU  ×  actions per user per day  ÷  seconds in a day  =  average QPS
 
 then apply a peak multiplier for sizing:
 
 peak QPS = average QPS × peak factor (typically 2–4x)

One day ≈ 86,400 s — round to 10⁵ for mental math. The rounding error (~16%) is irrelevant at design precision; the speed gained is not.

Worked Example: RideShare

Continuing the running example numbers:

 riders:   10M DAU × 14 app actions/day   = 140M requests/day
           140M ÷ 10⁵                     ≈ 1,400 rps average
           × 2.5 peak factor              ≈ 3,500 rps peak (read-heavy CRUD)

 matches:  20M trips/day ÷ 10⁵            ≈ 200 matches/sec average
           × 2.5                          ≈ 600/sec peak     ← the money path

 location pings (driver-side):
           ~170k concurrent trips × 0.25 pings/sec each
                                          ≈ 42k writes/sec average
           × 2.5                          ≈ 100k+/sec peak    ← dominates everything

Three different QPS classes fall out of one product — read traffic, transactional traffic, and telemetry traffic. They will be architected separately; the estimate’s job is to reveal that split.

Per-Endpoint QPS

System-wide QPS hides what matters. Break down by endpoint because components serve endpoints, not products:

Endpoint	Share of rider actions	Peak QPS
GET /feed, /history	~40%	1,400
POST /estimate	~15%	500
POST /ride (match)	~10%	350
GET /trip/status (during trips)	~25%	900
rest	~10%	350

The match row is 10% of volume and 90% of design attention — volume and importance are different axes.

Read vs Write Split Falls Out Naturally

The same action list yields the ratio used everywhere downstream:

 reads : writes ≈ 95 : 5 for typical consumer products
 RideShare overall is write-heavier than it looks BECAUSE
 location pings are silent writes — endpoint-level accounting
 catches this; system-level averages hide it

Common Estimation Mistakes

Mistake	Correction
Using registered users as DAU	Apply funnel ratios explicitly
Sizing on average, deploying for average	Peak factor is mandatory
One QPS number for the whole system	Split by endpoint class and storage impact
Forgetting fan-out amplification	1 user post → N feed reads generated server-side

The last one matters most for social systems: measured client QPS understates backend work when reads trigger internal fan-outs.

Interview Framing

QPS estimation takes two minutes and sets up every scaling argument. The scoring pattern: run the three-step chain aloud once for the headline number, immediately split into read/write/transactional classes, then bind each class to its future decision (“reads → cache+replicas; matches → strong path; pings → memory store”). A number that never gets consumed is wasted breath.