Capacity Numbers#
Numbers worth memorising for system design interview back-of-envelope estimation. Order-of-magnitude precision is enough.
Latency primitives#
The classic "Latency Numbers Every Programmer Should Know" (Jeff Dean), updated for modern hardware.
| Operation | Latency | Notes |
|---|---|---|
| L1 cache reference | 0.5 ns | |
| Branch mispredict | 5 ns | |
| L2 cache reference | 7 ns | |
| Mutex lock/unlock | 25 ns | |
| Main memory reference | 100 ns | RAM is ~200x slower than L1 |
| Compress 1 KB with Snappy | 3 µs | |
| Send 1 KB over 1 Gbps network | 10 µs | |
| Read 1 MB sequentially from RAM | 250 µs | |
| Round trip within same datacenter | 500 µs | |
| Read 1 MB sequentially from NVMe SSD | 1 ms | Modern NVMe: ~3 GB/s sequential |
| Disk seek (HDD) | 10 ms | NVMe seek is sub-100 µs |
| Read 1 MB from disk (HDD) | 20 ms | |
| Packet round trip CA → Netherlands → CA | 150 ms |
Key gaps to remember in interviews: - L1 → main memory: 200x - main memory → datacenter RTT: 5,000x - datacenter RTT → cross-continent: 300x - HDD seek → SSD seek: 100x
Throughput per single server#
Rough targets for a single commodity server (16-32 cores, 64-128 GB RAM, NVMe). Real numbers vary by workload by 10x in either direction; these are interview baselines.
| Workload | Throughput |
|---|---|
| HTTP static (nginx, cached) | 100k req/s |
| HTTP dynamic (typical app server) | 5k-10k req/s |
| Redis single-thread GET | 100k ops/s |
| Redis pipelined | 1M ops/s |
| Memcached | 200k ops/s |
| PostgreSQL OLTP point reads | 20k qps |
| PostgreSQL writes (single primary) | 5k tps |
| MySQL OLTP point reads | 30k qps |
| Cassandra writes | 20k-40k ops/s/node |
| DynamoDB / managed K-V | unlimited (scales horizontally; pay per RCU/WCU) |
| Kafka broker (3-broker cluster) | 1M msg/s writes |
| Elasticsearch indexing | 10k docs/s |
| Elasticsearch queries | 100-1000 qps depending on complexity |
| WebSocket open connections | 65k per IP, ~1M per host with tuning |
| Nginx open connections | ~10k by default, 1M+ with tuning |
| gRPC streaming | 100k msg/s per stream, multiple streams per conn |
Storage sizes#
| Item | Typical size |
|---|---|
| ASCII character | 1 byte |
| UTF-8 character (English) | 1 byte |
| UTF-8 character (CJK) | 3 bytes |
| Integer (32-bit) | 4 bytes |
| Long (64-bit) | 8 bytes |
| UUID v4 (binary) | 16 bytes |
| UUID v4 (string with hyphens) | 36 bytes |
| URL | 50-200 bytes typical, up to 2 KB worst case |
| Email address | 30-50 bytes typical |
| User profile row | 1-2 KB |
| Tweet / short post | 200-500 bytes |
| Blog post | 5-50 KB |
| Average web page | 2-3 MB |
| Thumbnail image | 10-30 KB |
| Full image (JPEG, 4K) | 500 KB - 2 MB |
| HD video (1080p, 1 minute) | 100-200 MB |
| 4K video (1 minute) | 500 MB - 1 GB |
| LLM embedding (768-dim float32) | 3 KB |
| LLM embedding (768-dim float16) | 1.5 KB |
| LLM embedding (1536-dim float32, OpenAI ada) | 6 KB |
Bandwidth & network#
| Link type | Bandwidth | RTT (typical) |
|---|---|---|
| Mobile 4G | 5-50 Mbps | 50-100 ms |
| Mobile 5G | 100 Mbps-1 Gbps | 10-50 ms |
| Home broadband | 100 Mbps-1 Gbps | 10-50 ms |
| Datacenter NIC | 10-100 Gbps | 0.5 ms |
| Cross-region (same continent) | (no limit) | 30-80 ms |
| Cross-continent | (no limit) | 100-200 ms |
Bandwidth-delay product (BDP) for TCP window sizing: - 1 Gbps × 100 ms = 12.5 MB in flight (need TCP window scaling) - 100 Mbps × 50 ms = 625 KB in flight
Daily / yearly aggregates#
Useful conversions for sizing exercises:
| Window | Duration |
|---|---|
| 1 hour | 3,600 s |
| 1 day | 86,400 s ≈ 10^5 s |
| 1 year | 31,536,000 s ≈ 3 × 10^7 s |
| 5 years | ≈ 1.5 × 10^8 s |
Quick rules of thumb: - 1 QPS sustained = 86,400 events/day = 31.5M events/year - 1,000 QPS sustained = 86M events/day = 31.5B events/year - A user who writes 1 KB/day for 1 year = 365 KB/user/year
Powers of 2 / SI conversion#
| 2^n | Value | SI ballpark |
|---|---|---|
| 2^10 | 1,024 | ~ 1 K |
| 2^16 | 65,536 | ~ 65 K |
| 2^20 | 1,048,576 | ~ 1 M |
| 2^30 | ~ 1 × 10^9 | ~ 1 G (1 billion) |
| 2^32 | ~ 4 × 10^9 | upper bound of 32-bit unsigned int |
| 2^40 | ~ 1 × 10^12 | ~ 1 T |
| 2^50 | ~ 1 × 10^15 | ~ 1 P |
| 2^60 | ~ 1 × 10^18 | ~ 1 E |
| 2^63 | ~ 9.2 × 10^18 | upper bound of 64-bit signed int |
Cost (cloud, mid-2025 list prices, before discounts)#
| Item | Cost |
|---|---|
| EC2 m6i.xlarge on-demand | $0.19/hr ≈ $140/month |
| EC2 1-yr reserved | ~ 40% off on-demand |
| EC2 3-yr reserved | ~ 60% off on-demand |
| EC2 spot | ~ 70-90% off on-demand (preemptible) |
| S3 Standard storage | $0.023/GB/month ≈ $23/TB/month |
| S3 Glacier Deep Archive | $0.00099/GB/month ≈ $1/TB/month |
| EBS gp3 storage | $0.08/GB/month ≈ $80/TB/month |
| Egress (S3 → internet) | $0.09/GB for first 10 TB |
| Egress (cross-region) | $0.02/GB |
| CloudFront egress | $0.085/GB (cheaper than direct S3) |
| RDS Postgres (db.m6g.large) | $0.16/hr + storage |
| DynamoDB on-demand write | $1.25 per million writes |
| DynamoDB on-demand read | $0.25 per million reads |
| ElastiCache (cache.m6g.large) | $0.13/hr ≈ $95/month |
| Lambda invocation | $0.20 per million + $0.0000166667 per GB-second |
LLM costs & throughput (Q4 2025)#
API pricing tier; on-prem vLLM serving is much cheaper but tied to GPU capex.
| Model class | Input | Output | TTFT (typical) | Throughput |
|---|---|---|---|---|
| GPT-4o | $2.50/1M tok | $10/1M tok | 300-500 ms | 80-150 tok/s |
| Claude Sonnet 4.5 | $3/1M tok | $15/1M tok | 300-600 ms | 50-100 tok/s |
| GPT-4o-mini / Haiku | $0.15-1/1M tok | $0.60-5/1M tok | 100-300 ms | 100-200 tok/s |
| Llama 3.1 70B (self-hosted, H100) | (capex) | (capex) | 200 ms | 30-60 tok/s per GPU |
| Llama 3.1 8B (self-hosted, A10) | (capex) | (capex) | 100 ms | 100+ tok/s per GPU |
| Embeddings (OpenAI ada-002) | $0.10/1M tok | n/a | 50 ms | 1000s req/s |
Typical conversation token counts: - 1 short message ≈ 50-100 tokens - 1 paragraph response ≈ 300-500 tokens - Full system prompt + context for an agent ≈ 2-5k tokens - A document chunk ≈ 500 tokens - 1 token ≈ 4 characters of English ≈ 0.75 words
Operating limits worth remembering#
| Item | Limit |
|---|---|
| Ephemeral ports (per IP) | ~ 28k usable (32k-60k range) |
| File descriptors per process | 1k default, 1M+ with ulimit -n |
| Linux max open TCP sockets (system-wide) | bounded by RAM; ~1M practical |
| Max URL length (browser-safe) | 2 KB |
| Max cookie size (per cookie) | 4 KB |
| Max DNS UDP packet size (legacy) | 512 bytes; modern eDNS extends to 4 KB |
| Max Ethernet frame (no jumbo) | 1,500 bytes MTU |
| Max TCP segment size | typically 1,460 bytes |
| Postgres row size | 8 KB page; rows TOASTed beyond |
| MongoDB document size | 16 MB hard limit |
| DynamoDB item size | 400 KB hard limit |
| S3 object size | 5 TB hard limit; multipart upload above 5 GB |
| Kafka message size | 1 MB default; configurable |
Famous "fits in" thresholds#
| Capacity | Fits |
|---|---|
| 1 GB RAM | ~ 1M user sessions |
| 16 GB RAM | full English Wikipedia text |
| 1 TB disk | ~ 250 hours of 4K video |
| 1 trillion seconds | ~ 31,700 years |
Worked example: Sizing Twitter#
A classic interview question. Use these numbers to ballpark:
- Users: 400M MAU, 200M DAU (Twitter scale)
- Tweets: each user tweets 2/day on avg → 400M tweets/day
- Tweet payload: 500 bytes → 200 GB/day ingest
- 5-year storage: 200 GB/day × 5 × 365 ≈ 350 TB (compressed maybe 100 TB)
- Reads: each user opens the app 5x/day, reads 100 tweets per session → 100B tweet reads/day = ~ 1M qps sustained → tweet read is the dominant load
- Fanout: a celebrity with 100M followers tweeting once produces 100M timeline insertions; sustained celebrity tweet rate (~1k/min) creates fanout storms
- Cost ballpark: 350 TB on S3 standard ≈ $8k/month for raw storage; serving at 1M qps via a CDN-fronted timeline costs much more in compute than storage
The point isn't precision; it's that you can defend each multiplication.
FAQ#
Why memorise capacity numbers?#
Most system design interviews include a sizing pass: estimate QPS, storage, bandwidth, cost. Knowing rough numbers lets you produce a defensible answer in 90 seconds instead of stalling on math.
How precise do these need to be?#
Order of magnitude. Interviewers don't fact-check exact figures; they look for whether you know the right ballpark and can multiply correctly. If memory says memory access is 100 ns and disk access is 10 ms, that's the gap you need: ~5 orders of magnitude.
Are these numbers from 2026?#
Latency primitives (memory, disk, network) shift slowly and are anchored to Jeff Dean's classic numbers updated for modern NVMe + datacenter networking. Cost numbers and LLM throughput change every few months; treat those as 2025 reference points.
What's a good interview drill?#
Pick a back-of-envelope question (design Twitter, estimate storage for a year of tweets), close this page, write a number, then open the page and check whether you were within 3x. Repeat until you're within 3x consistently.