When estimating the capacity of a system, think about:

• Traffic
• Latency
• Storage
• Memory
• Bandwidth
• Resources
• Costs

Useful Heuristics

• Writes are more expensive than reads — design for read-heavy workloads when possible
• Compression saves bandwidth — typical text compression: 3–10× reduction
• Max ~2,000 RTT/s within a datacenter — plan for batching if you need more
• Max ~7 RTT/s cross-region — minimize cross-region calls in hot paths
• Memory is ~100× faster than SSD, SSD is ~100× faster than HDD
• Network latency is dominated by distance — speed of light = ~3.3 µs per km (in fiber)
• Protobuf is ~3× smaller than JSON — consider for high-throughput APIs
• S3 is slow for small objects — batch or use a cache layer
• Redis can handle 100K+ ops/s — often the first caching choice
• Database connection overhead is ~1-5ms — use connection pooling
• CDN reduces latency by 10× — for static content, always use a CDN

Latency Numbers

Key formulas:

Total latency (serial operations):
Total = Latency₁ + Latency₂ + Latency₃ + ...

Total latency (parallel operations):
Total = max(Latency₁, Latency₂, Latency₃, ...)

Network latency estimation:
Min RTT ≈ Distance (km) × 2 ÷ 200,000 km/s (speed of light in fiber)
Example: NYC to London (5,500 km) = 5,500 × 2 ÷ 200,000 = 55 ms minimum

Percentile latencies (rule of thumb):
p50 ≈ median latency
p99 ≈ 2-10× p50 (depends on system)
p99.9 ≈ 2-5× p99

Latency budget allocation:
If target p99 = 200ms, allocate:
- Network: 20-30%
- Application: 30-40%
- Database: 30-40%
- Buffer: 10-20%

Availability & Downtime

Key formulas:

Downtime = (1 - Availability) × Time Period

Downtime/year  = (1 - availability) × 365 × 24 × 60 minutes
Downtime/month = (1 - availability) × 30 × 24 × 60 minutes
Downtime/week  = (1 - availability) × 7 × 24 × 60 minutes

Combined availability (serial):   A_total = A₁ × A₂ × A₃ × ...
Combined availability (parallel): A_total = 1 - (1 - A₁) × (1 - A₂) × ...

Example (serial): Two services at 99.9% each → 0.999 × 0.999 = 99.8%
Example (parallel): Two services at 99% each → 1 - (0.01 × 0.01) = 99.99%

Traffic Estimation (Requests ↔ RPS)

Key formulas:

• 1 month ≈ 2.5 million seconds
• 1 day ≈ 86,400 seconds ≈ 100K seconds

Quick conversion:

• Monthly → Daily: divide by 30
• Daily → RPS: divide by 100K (or 86,400)
• Monthly → RPS: divide by 2.5M

Network & Bandwidth

Bits vs Bytes conversion:
Network speeds are in bits/s, storage throughput is in bytes/s.
Divide by 8: 1 Gbps = 125 MB/s

Key formulas:

Throughput (bytes/s) = Network speed (bits/s) ÷ 8

Transfer time = Data size ÷ Throughput
Example: 1 GB over 1 Gbps = 1024 MB ÷ 125 MB/s ≈ 8 seconds

Bandwidth needed = Data size × Requests per second
Example: 1 MB responses × 1000 RPS = 1 GB/s = 8 Gbps

With compression (typical 3× reduction):
Effective bandwidth = Raw bandwidth × Compression ratio
Example: 1 Gbps × 3 = 3 Gbps effective for compressible data

Quick Mental Math Rules

Key formulas:

Storage estimation:
Total storage = Object size × Number of objects × Replication factor × Time period

Example: 1 million users × 10 KB profile × 3 replicas = 30 GB

Storage growth/year = Daily new data × 365
Example: 100 GB/day × 365 = 36.5 TB/year

Bandwidth estimation:
Peak bandwidth = Average bandwidth × Peak factor (typically 2-10×)
Daily bandwidth = Average request size × Daily requests

QPS/RPS estimation:
Average QPS = Total requests ÷ Time period in seconds
Peak QPS = Average QPS × Peak factor (typically 2-3×)

Cache size estimation:
Cache size = Working set × Object size
Working set = Total objects × Access frequency factor (typically 20%)

Example: 1M users, 20% daily active, 10 KB each = 2 GB cache

Number of servers:
Servers needed = Peak QPS ÷ QPS per server
Add 30% headroom for failover

Example: 10,000 QPS ÷ 1,000 QPS/server × 1.3 = 13 servers

Time Units

Powers of Two

Binary (IEC) vs Decimal (SI) Units

Usage conventions:

• RAM & memory: Usually binary (a “16 GB” RAM stick is really 16 GiB)
• Storage (HDD/SSD): Usually decimal (a “1 TB” drive is 1,000 GB, not 1,024 GB)
• Network speeds: Always decimal (1 Gbps = 1,000,000,000 bits/s)
• Linux tools: ls -l shows bytes; use ls -lh for human-readable (binary)

Key formulas:

1 KiB = 2¹⁰ bytes = 1,024 bytes
1 MiB = 2²⁰ bytes = 1,024 KiB ≈ 1.049 MB
1 GiB = 2³⁰ bytes = 1,024 MiB ≈ 1.074 GB
1 TiB = 2⁴⁰ bytes = 1,024 GiB ≈ 1.100 TB
1 PiB = 2⁵⁰ bytes = 1,024 TiB ≈ 1.126 PB

Quick estimate: 2¹⁰ ≈ 10³ (off by 2.4%)
Therefore: 2ⁿ ≈ 10^(n × 0.3)

Converting binary to decimal:
GiB to GB: multiply by 1.074
TiB to TB: multiply by 1.100

Example: 500 GiB SSD = 500 × 1.074 = 537 GB
Example: "1 TB" HDD = 1000 GB = 931 GiB (what OS shows)

Database & Cache Latencies

Key formulas:

Cache hit ratio:
Hit ratio = Cache hits ÷ (Cache hits + Cache misses)
Target: > 90% for effective caching

Average latency with cache:
Avg latency = (Hit ratio × Cache latency) + ((1 - Hit ratio) × DB latency)

Example: 95% hit ratio, 1ms cache, 10ms DB
= (0.95 × 1) + (0.05 × 10) = 0.95 + 0.5 = 1.45 ms

Cache capacity planning:
Memory needed = Number of cached items × Average item size × Overhead (1.2-1.5×)

Database connections:
Max connections = (Number of servers × Connections per server)
Rule of thumb: PostgreSQL handles ~100-500 connections well
Use connection pooling (PgBouncer) for more

IOPS estimation:
Required IOPS = QPS × Queries per request × (1 + Cache miss ratio)

Cloud Storage Latencies

Cloud storage throughput:

• Single S3 connection: ~100 MB/s
• Multi-part parallel upload: 1–5 GB/s achievable
• S3 request rate: ~5,500 PUT/s, ~5,500 GET/s per prefix

Key formulas:

S3 cost estimation:
Storage cost = GB stored × $0.023/GB/month (standard tier)
Request cost = (PUT requests × $0.005/1000) + (GET requests × $0.0004/1000)
Transfer cost = GB transferred out × $0.09/GB (to internet)

CDN cost estimation:
CDN cost = GB transferred × $0.085/GB (first 10TB)
Savings = Origin requests avoided × Origin cost per request

Multipart upload calculation:
Parts needed = File size ÷ Part size (min 5MB, max 5GB)
Upload time = File size ÷ (Parallel connections × Per-connection throughput)

Example: 10 GB file, 10 parallel connections, 100 MB/s each
= 10,000 MB ÷ (10 × 100 MB/s) = 10 seconds

Typical Payload Sizes

Key formulas:

Image size estimation:
Uncompressed = Width × Height × Bytes per pixel (3 for RGB, 4 for RGBA)
Example: 1920×1080×3 = 6.2 MB uncompressed
Compressed JPEG ≈ Uncompressed ÷ 10 = ~600 KB

Video size estimation:
Bitrate (Mbps) × Duration (seconds) ÷ 8 = Size in MB
Example: 5 Mbps × 60 sec ÷ 8 = 37.5 MB

Audio size estimation:
Bitrate (kbps) × Duration (seconds) ÷ 8 = Size in KB
Example: 128 kbps × 60 sec ÷ 8 = 960 KB ≈ 1 MB

Log storage estimation:
Daily logs = Log lines per second × 86,400 × Avg log size
Example: 1000 logs/sec × 86,400 × 300 bytes = 25.9 GB/day

JSON vs Protobuf:
Protobuf size ≈ JSON size × 0.3
Protobuf parse time ≈ JSON parse time × 0.1

Serialization Format Comparison

Common System Capacities

Key formulas:

Connection limits:
Max TCP connections = 65,535 per IP (port range)
With multiple IPs: Max connections = 65,535 × Number of IPs

Thread pool sizing (CPU-bound):
Optimal threads = Number of CPU cores

Thread pool sizing (I/O-bound):
Optimal threads = Number of cores × (1 + Wait time / Service time)
Example: 8 cores, 100ms wait, 10ms service = 8 × (1 + 10) = 88 threads

Little's Law (queue sizing):
L = λ × W
L = Average number in system
λ = Arrival rate (requests/second)
W = Average time in system

Example: 1000 RPS, 100ms latency → 1000 × 0.1 = 100 concurrent requests

Amdahl's Law (parallelization speedup):
Speedup = 1 / ((1 - P) + P/N)
P = Parallelizable fraction
N = Number of processors

Example: 90% parallelizable, 10 cores → 1 / (0.1 + 0.9/10) = 5.26× speedup

Message Queue Comparison

When to use what:

• Kafka: Event sourcing, log aggregation, high-throughput streaming
• RabbitMQ: Task queues, complex routing, RPC patterns
• SQS: Serverless, simple decoupling, no ops overhead
• Redis Streams: Low-latency, already using Redis

Container & Kubernetes Overhead

Cold start times (serverless):

DNS & TLS Overhead

Optimization tips:

• Use HTTP/2 or HTTP/3 — multiplexing reduces connection overhead
• Enable TLS session resumption — avoids full handshake
• Use connection pooling — reuse existing connections
• Pre-resolve DNS — dns-prefetch hint in browsers
• Keep-alive connections — avoid TCP + TLS setup per request

Cost Ballpark (Cloud, 2025)

Rule of thumb: Egress costs often dominate — design to minimize cross-region and internet data transfer.

Common Data Type Sizes

Primitive Types (C/Java/Go)

PostgreSQL Numeric Types

PostgreSQL String Types

String storage: 1–4 bytes overhead + actual string length. Strings > 2KB are automatically compressed (TOAST).

PostgreSQL Date/Time Types

PostgreSQL Other Common Types

Common Identifiers

Key formulas:

UUID collision probability (Birthday Problem):
P(collision) ≈ 1 - e^(-n² / 2 × 2¹²²)
For 1 billion UUIDs: P ≈ 10⁻¹⁸ (effectively zero)

ID space exhaustion:
Time to exhaust = Max IDs ÷ IDs per second
32-bit at 1000/s = 2.1B ÷ 1000 = 24 days
64-bit at 1M/s = 9.2 quintillion ÷ 1M = 292,000 years

Snowflake ID structure (64-bit):
- 1 bit: sign (always 0)
- 41 bits: timestamp (69 years from epoch)
- 10 bits: machine ID (1024 machines)
- 12 bits: sequence (4096 IDs/ms/machine)
Max: 4096 × 1000 × 1024 = 4.2 billion IDs/second globally

PostgreSQL Row Overhead

Key formulas:

Row size estimation:
Row size = 23 bytes (header) + NULL bitmap + Column data + Padding

Table size estimation:
Table size = Number of rows × Average row size × Bloat factor (1.2-1.5)

Index size estimation:
B-tree index ≈ Number of rows × (Key size + 8 bytes) × 2-3× overhead
Example: 10M rows, 8-byte key = 10M × 16 × 2.5 = 400 MB

TOAST threshold: Values > 2KB are compressed/stored externally

Pages and blocks:
PostgreSQL page size = 8 KB
Rows per page ≈ 8192 ÷ Row size (minus page header ~24 bytes)
Example: 100-byte rows → ~80 rows per page

Fill factor (default 90% for tables):
Usable space per page = 8192 × 0.9 = 7373 bytes