User Personas & Workloads

From People to Numbers

Personas answer who; workloads convert them into how much of what. Together they are the bridge between requirements and every capacity number in the design. Skipping this step makes later estimates guesswork.

Step 1 — Personas (behavioral classes, not demographics)

A persona is a usage pattern that loads the system differently:

Persona	Behavior	System load signature
Commuter rider	2 rides/day, fixed routes, opens app briefly	Predictable peaks at rush hours
Night-out rider	Weekend nights, groups, surge-tolerant	Sharp weekend spikes
Full-time driver	8–10 hrs online, constant location pings	Continuous write stream
Casual driver	Evenings only	Adds to peak overlap

Two riders with identical demographics but different patterns belong in different personas. The classification axis is load behavior, not marketing segments.

Step 2 — Action Frequencies per Persona

Attach numbers to each persona’s session (illustrative):

 RIDER SESSION (per active day):
   app open + browse        ~8 requests
   fare estimates           ~3
   ride request/match       2   ← the money path
   location updates sent    during-trip only
   history view             ~1

 DRIVER ONLINE HOUR:
   location ping            every 4 s     = 900/hr
   match offers seen        ~30/hr
   status flips             ~12/hr
 
 → drivers are WRITE-heavy citizens; riders are READ-heavy ones

That asymmetry — invisible without persona analysis — dictates that driver location ingestion needs its own pipeline, not shared CRUD endpoints.

Step 3 — Aggregate into Workload Mix

Multiply personas × population × frequency → system totals (10M rider DAU, 500k full-time-equivalent drivers):

 REQUESTS/DAY (illustrative)
 riders : 10M × 14 actions              ≈ 140M requests/day  ≈ 1.6k rps avg
 drivers: location pings 500k × 9hr × 900  ≈ 4B pings/day   ≈ 47k rps avg
          ↑ one "boring" background action dominates total traffic
 matches: 20M trips/day                 ≈ 230/s avg, ~600 peak

 WORKLOAD MIX by weight:  writes(location) 96% | reads(browsing) 3%
                          | transactions(matches+payments) 1%

The punchline every workload analysis produces eventually: the highest-value traffic is not the highest-volume traffic. Architecture must serve both — cheap massive paths for pings, premium small paths for matches.

Peak Shapes, Not Just Averages

Workloads have a shape over time; averages hide it:

 rides/hour (dense city)
      ▲            ╭──╮          morning + evening plateaus,
      │         ╭──╯  ╰─╮       late-night spike (weekends)
      │      ╭──╯       ╰╮╭─╮
      ├─────╯            ╰╯ ╰────
      └──────────────────────────► hour of day
        0    6    9   12   17 19  23
        
 peak:average ≈ 2.5x on weekdays, 4x event weekends
 → capacity sized to peak, cost optimized against average

Interview Framing

This lesson is where “assume 10M DAU” becomes design-grade input. The scoring move: derive two or three aggregate numbers live from stated persona behavior, then immediately use one (“that 50k pings/sec means locations never touch Postgres”). Numbers that get used signal method; numbers left dangling signal ritual.