Estimating Users

Not All “Users” Are the Same Number

“1M users” is meaningless until classified — each class drives a different design decision:

 REGISTERED ACCOUNTS   50M     → storage for profiles, rows in users table
 MONTHLY ACTIVE (MAU)  15M     → product reach; weak capacity signal
 DAILY ACTIVE (DAU)    4M      → primary traffic driver ← most estimates start here
 PEAK CONCURRENT       200k    → sizing instantaneous load (connections, memory)
 
 DAU/MAU ratio ≈ 0.27  → habit metric; sticky products approach 0.5+

Capacity math runs off DAU and peak concurrency — never registered count, which only inflates storage estimates modestly.

Building the Estimate

Start from whatever anchor the prompt gives, then climb to daily activity:

 GIVEN: "design for a Twitter-like app with 100M registered users"

 typical funnel ratios (illustrative, state them as assumptions):
   registered        100M
   MAU  ~40%      →   40M
   DAU  ~25% of MAU →  10M
   
 sessions per DAU          ~3/day
 actions per session       ~10
 ─────────────────────────────────
 total actions/day         300M    ← feeds every later estimate

Each ratio is an assumption — declared, defensible, adjustable when the interviewer corrects it.

Peak Concurrent Users

DAU spreads over a day unevenly; what matters for connection/memory sizing is simultaneous presence:

 rule-of-thumb: peak concurrent ≈ 5–10% of DAU for consumer apps

 10M DAU × 7% ≈ 700k concurrent at evening peak
 
 what this sizes:
 - websocket connections (if realtime): memory per conn × 700k
 - match/session state held in RAM
 - NOT average QPS (that comes from actions/day)

Growth Projection: Design Target ≠ Today’s Number

Designing for today guarantees a redesign next quarter. The working pattern:

Horizon	Users	Purpose
Today	10M DAU	Baseline architecture must handle this now
+12 months	25M DAU (2.5x)	Architecture must evolve here without rewrite
Ceiling	100M	Components chosen so this is sharding work, not re-architecture

The standard interview stance: build comfortably for today, choose components whose next stage is known — e.g., Postgres now with a named sharding path, not Cassandra on day one for a hypothetical.

Sanity Checks

Estimates go wrong in two directions — both checkable:

• Too big: claiming 100M DAU for a niche B2B tool collapses under one follow-up (“who are these users?”).
• Too uniform: forgetting diurnal/geographic clustering makes every downstream number wrong by the peak factor (covered next lesson).

Interview Framing

This estimation opens nearly every design interview. The scoring shape: classify user counts explicitly, derive DAU from stated assumptions, compute peak concurrent, project a growth multiple, then say which later decisions each number will drive. Numbers announced as inputs-to-decisions read as method, not recital.