Read-Write Ratio

The Ratio That Picks Architectures

Every workload is some mix of reads and writes, and the mix is destiny:

 READ-HEAVY (100:1)                WRITE-HEAVY (1:10)

 social feeds, product pages,      logs, metrics, location pings,
 news, catalogs, search            telemetry, click streams

 strategy: cache aggressively,     strategy: append-only stores,
 replicas, CDN                     LSM engines, batching, queues
 - reads served from memory        - optimize ingestion throughput
 - writes rare → any DB handles    - reads secondary/analytic

Same product can contain both — RideShare already showed browsing at 95% reads while location pings run 100% writes. Ratios are per data type, never one number per company.

Deriving the Ratio from Actions

The action list from persona analysis converts directly (illustrative):

 RIDER ACTIONS/DAY                    CLASS
 browse feed/history     60M          READ
 fare estimates          20M          READ (compute-light)
 trip status polls       40M          READ
 ride requests/matches   20M          WRITE (transactional)
 ratings, profile edits  5M           WRITE
 
 rider totals: 120M reads / 25M writes ≈ 5:1

 DRIVER TELEMETRY:
 location pings          4B/day       WRITE
 ─────────────────────────────────────────────
 system-wide: ~4.2B writes vs 120M reads ≈ 1:35 WRITE-DOMINATED

One silent background stream flipped a read-heavy product into a write-heavy system — endpoint-level accounting catches what intuition misses.

What the Ratio Decides Downstream

Ratio	Storage shape	Cache posture	Scaling lever
1000:1	Normalized relational fine	Aggressive + CDN; stale tolerable	Replicas, edge
100:1	Relational + read replicas	Standard TTL caching	Replica count
10:1	Index-heavy; watch write amplification	Selective caching	Vertical + partitioning
1:1	B-tree stress; consider LSM	Little use for hot writes	Sharding writes early
1:100	Append-only, LSM/log-structured	N/A — pre-aggregates instead	Partitioned ingestion

Write amplification deserves its own flag: every index on a table multiplies write cost. A 1:1 workload with five indexes pays six writes per logical insert.

Mixed Workloads: The Real Answer

Production systems almost always split by data type rather than picking one engine:

 RideShare split:
 locations  → Redis/memory geo store     (pure writes, ephemeral)
 trips      → Postgres primary+replicas  (transactional, balanced)
 history    → same PG replicas + cache   (read-dominated view of trips)
 analytics  → warehouse via CDC          (write-once, read-analyzed)
 
 each path gets ITS ratio's architecture — that IS polyglot design

Interview Framing

State ratios per subsystem and immediately bind them to choices (“history is ~50:1 so replicas + Redis carry it; matching is write-consistent so it stays transactional”). When an interviewer shifts the ratio (“imagine drivers ping every second”), strong candidates re-run the affected numbers and let the conclusion move — the ratio is an input to reasoning, not a slogan.