Numbers to Memorize

Latency numbers tell you what can fit inside a request path. A few CPU cache reads are invisible. A disk seek is enormous by comparison. A cross-region round trip can consume an entire user-facing budget before your application code runs.

Storage estimates are easier if you can move between bytes, KB, MB, GB, TB, and PB without pausing. Engineers often use powers of two while product estimates use round powers of ten. For back-of-the-envelope work, the rounded decimal values are usually close enough.

1 KiB = 1,024 bytes          ≈ 1 KB
1 MiB = 1,024 KiB            ≈ 1 MB
1 GiB = 1,024 MiB            ≈ 1 GB
1 TiB = 1,024 GiB            ≈ 1 TB

Back-of-envelope shortcuts:
  1 KB * 1 million items  ≈ 1 GB
  1 KB * 1 billion items  ≈ 1 TB
  1 MB * 1 million items  ≈ 1 TB
  1 MB * 1 billion items  ≈ 1 PB

The exact binary values matter for billing and filesystem limits. The rounded values matter for fast reasoning: if every message is 1 KB and you store 1 billion messages, you are in terabyte territory before replication, indexes, or backups.

Most capacity chains start with daily active users and actions per day. Convert daily actions into average QPS by dividing by 86,400 seconds per day. Then multiply by a peak factor because real traffic is not flat.

• Average QPS: total daily actions divided by 86,400.
• Peak QPS: average QPS multiplied by a peak factor. Design for peak unless the workload can queue safely.
• Read/write split: many products have far more reads than writes. Estimate them separately when cache, database, and fanout requirements differ.

Per-node throughput depends on hardware, payload size, indexes, replication, consistency, and code quality. These numbers are not promises; they are sanity checks. If your estimate requires one database node to handle 2 million complex writes per second, something is wrong.

The point is to divide peak load by plausible capacity. If you need 600K peak API QPS and one app node safely handles 5K QPS with headroom, you are in the neighborhood of 120 app nodes before redundancy and regional distribution.

Object size estimates drive storage, bandwidth, cache, and database design. Include metadata, indexes, replication, compression, retention, and fanout copies. The user-visible payload is rarely the whole cost.

Hidden multipliers to remember

• Replication: three copies turn 100 TB of logical data into roughly 300 TB of raw storage.
• Indexes: secondary indexes can be as large as, or larger than, the base data for write-heavy tables.
• Retention: 7 days vs. 365 days changes storage by 52×.
• Fanout: a single post may be stored once in the origin table but referenced or copied into millions of timelines.

Start with the memorized anchors, then run the capacity chain: users → actions → QPS → storage → bandwidth → node count. The goal is not to be perfectly correct; it is to expose which part of the system is large enough to shape the architecture.

• At 100 QPS, architecture is dominated by correctness and simplicity.
• At 100K QPS, caches, load balancing, partitioning, and observability become central.
• At petabytes, retention, compaction, lifecycle policies, and storage tiering become product features, not cleanup details.