Cheat Sheet
Key takeaway
A BOTEC answers "is this feasible, and what binds first?" Estimate compute, connections, storage, and bandwidth; the largest one dictates the architecture. State every assumption, round hard, and sanity-check the result before you say it out loud.
The method
1. State assumptions (DAU, actions/user/day, item sizes, retention) 2. Multiply through (QPS, storage, bandwidth, connections) 3. Plausibility check (convert to disks, links, machines, money) 4. Name the binding constraint -> that's your architecture
Latency numbers
| Operation | Time |
|---|---|
| L1 cache reference | 0.9 ns |
| L2 cache reference | 2.8 ns |
| L3 cache reference | 12.9 ns |
| Main memory reference | 100 ns |
| Compress 1 KB with Snzip | 3 us |
| Read 1 MB sequentially from memory | 9 us |
| Read 1 MB sequentially from SSD | 200 us |
| Round trip within same datacenter | 500 us |
| Read 1 MB from SSD at ~1 GB/sec | 1 ms |
| Read 1 MB sequentially from disk | 2 ms |
| Disk seek | 4 ms |
| Round trip SF to NYC | 71 ms |
Disk seek (4 ms) costs more than reading 1 MB sequentially (2 ms) — finding data beats reading it. Hence sequential access and batching.
Throughput rates
| System | QPS | Why |
|---|---|---|
| MySQL | 1,000 | Parse, plan, optimize, execute |
| Key-value store | 10,000 | Simple put/get, no query planning |
| Cache server | 100,000 – 1 M | In-memory only; read-heavy goes higher |
Remember one number and two ratios, not three facts.
Reference server
| Component | Spec |
|---|---|
| Cores | 64 |
| RAM | 256 GB |
| L3 cache | 112.5 MB |
| Storage | 16 TB |
| Cloud equivalent | AWS m7i.16xlarge, 25 Gbps NIC, ~3.55 USD/hour |
Derived capacity: ~1 ms CPU per request → 1,000 RPS/core → 64,000 RPS/server (CPU-bound ceiling).
Server roles
| Role | Processor | RAM | Disk | Real example |
|---|---|---|---|---|
| Web server | High | Medium | Medium | Facebook: 32 GB RAM, 500 GB |
| Application server | High | High | High | Facebook: 256 GB RAM, 6.5 TB hybrid |
| Storage server | Low | Low | High | Facebook: up to 120 TB, only 32 GB RAM |
Plus the servers nobody diagrams: config, monitoring, load balancing, analytics, accounting, caching.
Request classes
CPU-bound = X compress, hash, encode (3 us) Memory-bound = 10X large in-memory scans (9 us) IO-bound = 100X disk reads, network calls (200 us)
Low CPU + high latency = IO-bound. More cores won't help; cache, batch, and cut round trips.
The formulas
Total requests/day = DAU * actions per user per day Average QPS = requests/day / 86,400 (use 100,000) Peak QPS = average * peak factor Servers = peak QPS / RPS per server Connections = concurrent users / connections per server Storage/day = items/day * bytes per item Total storage = storage/day * retention days * replication factor Bandwidth (Gbps) = (bytes/sec) * 8 <- ALWAYS the x8
Peak factors
| Traffic shape | Factor |
|---|---|
| Global always-on (messaging) | 2x – 3x |
| Regional consumer app | 3x – 5x |
| Event-driven (tickets, news) | 10x – 100x |
| Pareto 80/20 rule of thumb | ~4x average |
Pareto: 80% of traffic in 20% of the day = a 4.8-hour window (17,280 sec).
The Twitter worked example
500M DAU · 20 requests/user/day · 64,000 RPS/server Uniform over 24h -> 2 servers (lower bound, fails plausibility) Pareto 80/20 -> 8 servers (planning figure) All at once -> 157,000 servers (pathological bound)
| Scenario | Servers | Per hour | Per year |
|---|---|---|---|
| Lower bound | 2 | 7.10 USD | ~62K USD |
| Pareto | 8 | 28.38 USD | ~249K USD |
| Peak load | 157,000 | 557,061 USD | ~4.88 billion USD |
Storage (500M DAU, 3 tweets/day, 10% image at 200 KB, 5% video at 3 MB, 250 B text):
Text 375 GB | Images 30 TB | Videos 225 TB -> 255 TB/day -> 93 PB/year
Bandwidth (50 tweets viewed/user/day → 289K views/sec):
In 24 Gbps + Out 393.62 Gbps = 417.62 Gbps (text 0.58 · images 46.24 · videos 346.8)
Video is ~5% of items and ~88% of both storage and egress. Always break down by content type.
Useful constants
| Quantity | Value |
|---|---|
| Seconds in a day | 86,400 (use 100,000) |
| Seconds in a year | ~31.5 million |
| 1 million/day | ~12/sec |
| 1 billion/day | ~11,600/sec |
| Bytes → bits | x8 |
| 1 exabyte | 10^18 bytes (storage is base 10) |
Quick decision cues
- Result fails the smell test → an assumption is broken, not the arithmetic
- Estimate is a lower bound → you assumed uniform traffic; apply a peak factor
- Media in the payload → break storage and bandwidth down by content type
- Egress in the Tbps → CDN is the architecture, not an optimization
- Persistent connections → estimate connections, they often bind before CPU
- Low CPU, high latency → IO-bound; cache and batch before scaling out
- Off by 2x doesn't change the conclusion → state the assumption and move on
- Can't provision for the peak → degrade: drop personalization, go CDN-static
- Storage growing unbounded → the lever is retention and compression
Work the Interview Walkthrough for a full live run, and the Estimation Drills for timed practice.