Requests Per Second Math

The Pipeline

Every rps estimate walks the same four steps:

 1. users        DAU (never registered count)
 2. actions      requests per user per day
 3. average      users × actions ÷ 10⁵ seconds
 4. peak         average × peak factor (2–3x typical)

Worked Across Product Shapes

URL shortener (write-light, redirect-heavy)

 100M redirects/day, 5M new links/day
 reads : 100M ÷ 10⁵ = 1,000 rps avg → 2,500–3,000 peak
 writes:   5M ÷ 10⁵ =    50 rps avg → ~125 peak
 ratio ≈ 20:1 read-heavy → cache/CDN-first design

Chat app (fan-out heavy)

 50M DAU × 40 messages sent/day each = 2B msgs/day
 writes: 2B ÷ 10⁵ = 20,000 msg/sec avg → 50k+ peak
 reads:  delivered via push connections — measured as fan-out:
         avg recipient count × message rate = the REAL load number
 
 lesson: some products' dominant cost hides inside delivery,
 not request counts

Video platform (bandwidth-dominated)

 5M views/day... but rps is nearly irrelevant here:
   views: ~60 rps avg — trivially small
   bytes: 1M concurrent viewers × 4 Mbps = 4 Tbps egress
   
 lesson: identify which resource DOMINATES; sometimes it isn't requests

The Action-Count Discipline

“Actions per user per day” needs honest decomposition:

 social feed user's day (illustrative):
   app opens            6    (each: feed fetch + presence ping)
   scroll depth         ~20 API pages total
   likes/comments       8
   profile views        3
   ─────────────────────────
   ≈ 37 backend requests/user/day

 20M DAU × 37 = 740M/day ≈ 7,400 rps avg ≈ 18k rps peak

Undercounting background actions (presence pings, polls, prefetch) is the classic miss — real client telemetry usually shows 2–5x more requests than feature lists suggest.

Split Before You Size

One aggregate number sizes nothing. The split does:

 18k rps peak splits into:
   feed reads        60%   → cache tier sizing
   media metadata    15%   → DB read path
   writes (posts)     5%   → primary write ceiling check
   presence/polling  20%   → connection-tier sizing
   
 each row now has an owner component and a capacity conversation

Interview Framing

Run the four-step pipeline aloud once for the headline endpoint, then split by class and bind to components. When interviewers adjust inputs (“make it 500M DAU”), strong candidates scale linearly except where linearity breaks (cache hit ratios shift, shard counts cross thresholds) — noting those inflections is what turns arithmetic into design.