Cheat sheet

Latency numbers every programmer should know

Capacity formulas

── TRAFFIC ──────────────────────────────────────────────────────
seconds/day        = 86,400            # round to 100,000
QPS                = daily / 86,400
1M/day             ≈ 12 QPS
1B/day             ≈ 12,000 QPS
peak QPS           = avg × 2 to 10     # use ×3 by default

── STORAGE ──────────────────────────────────────────────────────
daily bytes        = writes/day × bytes/write
5-year storage     = daily × 365 × 5 × replication (×3)
                     + indexes (often +30–100% of table size)

── BANDWIDTH ────────────────────────────────────────────────────
bandwidth          = QPS × payload     # reads and writes separately
                     >1 GB/s egress → it is a CDN problem, not an origin one

── FLEET ────────────────────────────────────────────────────────
servers            = peak QPS / per-server QPS × 1.5   # headroom
app server         ≈ 5k–15k QPS (I/O bound), hundreds (CPU bound)
Redis node         ≈ 100k ops/s
Postgres primary   ≈ 10k–50k simple writes/s
Kafka broker       ≈ 100k+ msgs/s, ~10 MB/s per partition
one gateway node   ≈ 50k–100k WebSocket connections

── CACHE ────────────────────────────────────────────────────────
DB QPS             = total QPS × (1 − hit rate)
memory needed      = items × avg size × 1.2
95% → 99% hit rate = 5× less database load   # the last points matter most

── AVAILABILITY ─────────────────────────────────────────────────
99%      3d 15h/yr      99.9%    8h 46m/yr
99.95%   4h 23m/yr      99.99%   52m/yr        99.999%  5m 15s/yr
series (dependencies)   A₁ × A₂ × … → 5 × 99.9% = 99.5%
parallel (redundancy)   1 − (1−A)ⁿ  → 2 × 99%   = 99.99%

── QUORUM ───────────────────────────────────────────────────────
W + R > N          → reads see the latest write
N=3, W=2, R=2      → balanced, survives one failure

Units and sizes to reason with

Decision trees

Which datastore?

Do you need transactions across multiple rows/entities?
├─ YES → relational (Postgres). Past one node → shard, or Spanner/Cockroach.
└─ NO  → What is the access pattern?
         ├─ purely by key, huge scale       → key-value (DynamoDB, Redis)
         ├─ nested docs, flexible schema    → document (MongoDB)
         ├─ write-heavy, time-ordered rows  → wide-column (Cassandra)
         ├─ multi-hop relationships         → graph (Neo4j)
         ├─ metrics over time               → time-series (Prometheus, Timescale)
         └─ relevance-ranked text           → search (Elasticsearch) — as a
                                              DERIVED index, never the truth

Sync or async?

Does the user need the result on this screen, now?
├─ YES → synchronous. Then: can it be slow?
│        ├─ no  → cache it, precompute it, or make the dependency optional
│        └─ yes → timeout + circuit breaker + a degraded fallback
└─ NO  → asynchronous. Then: does anyone else care about the event?
         ├─ one worker should do it   → queue
         └─ several systems, + replay → log (Kafka)

Fan-out on write or on read?

reads ≫ writes and the audience is bounded?     → fan-out on WRITE
writes ≫ reads, or the audience is enormous?    → fan-out on READ
power-law audience (a few huge accounts)?       → HYBRID:
      push for normal accounts, pull for celebrities, merge at read

Which consistency?

Is being wrong for 2 seconds a bug or a shrug?
├─ BUG (money, inventory, auth, locks, uniqueness) → strong/linearizable,
│    keep it in one region, accept the latency
├─ ORDER MATTERS but global order doesn't (replies, chat) → causal
└─ SHRUG (likes, views, feeds, presence) → eventual + session guarantees
     (read-your-writes and monotonic reads remove most visible weirdness
      for almost no cost)

Where does the bottleneck go next?

Slow reads       → index → cache → read replica → denormalise → CDN
Slow writes      → batch → async → partition → change the storage engine
Too much data    → tier/archive → partition → compress → sample
Too many conns   → pooling → gateway tier → protocol change
Too slow overall → measure first. It is almost never where you think.

Pattern index — problem to pattern

Sensible defaults to reach for

The 60-second opener, memorised