Back-of-envelope estimation is not about precision — it's about order of magnitude. The goal is to identify whether you're designing for thousands, millions, or billions of operations per second, because that determines the entire architecture. Interviewers aren't checking your arithmetic — they're checking that you anchor decisions in reality rather than vibes.
Time units. 1 minute = 60 seconds. 1 hour = 3,600 seconds. 1 day = 86,400 seconds (~100K). 1 year = 31.5 million seconds (~30M). Shortcut: 1 day ≈ 100K seconds (error: 15%). Use 100K for rough calculations.
Storage units. 1 KB = 1,024 bytes ≈ 1K. 1 MB = 1,024 KB ≈ 1M bytes. 1 GB = 1,024 MB ≈ 1B bytes. 1 TB = 1,024 GB. 1 PB = 1,024 TB. A tweet: ~300 bytes. A high-res photo: ~3 MB. A 1-hour HD video: ~1 GB.
Latency numbers. L1 cache: 1 ns. RAM access: 100 ns. SSD random read: 150 µs. Network (same datacenter): 0.5 ms. HDD random read: 10 ms. Network (cross-region US): 40 ms. Network (US to Europe): 150 ms. Ratios to internalize: RAM is 1,000× faster than SSD. SSD is 1,000× faster than HDD. In-datacenter network is 300× faster than cross-Atlantic.
Throughput of common components. Single web server: 10,000–50,000 requests/second. Single PostgreSQL node (OLTP): 10,000–50,000 queries/second. Redis: 100,000–1,000,000 operations/second. Kafka: 1,000,000+ messages/second per broker. 1 Gbps network link: ~125 MB/second. 1 CPU core: ~1 billion simple operations/second.
QPS = (DAU × actions_per_user_per_day) / 86,400
This is the formula you'll use in every interview. The inputs are from your requirements clarification. You derive DAU from MAU using the engagement ratio (typically 10–20% for general consumer apps; 40–67% for high-engagement apps). Actions per user per day is context-specific — ask the interviewer or estimate from the product description.
Peak vs average. The QPS formula gives average QPS. Peak QPS is 2–5× average. Use 3× as a safe default unless the product has specific peak characteristics (a sports streaming service peaks at match time — use 10× average for that 2-hour window). Your architecture must handle peak QPS, not average.
Read/write ratio. Most consumer apps are read-heavy: 10:1 to 100:1 reads to writes. Social feeds: ~100:1 (everyone reads, few write). E-commerce catalog: ~50:1. Messaging apps: ~3:1 (more balanced). The read QPS determines your caching strategy; the write QPS determines your database write capacity.
Daily storage = records_created_per_day × bytes_per_record
Total storage = daily_storage × retention_days
Bytes per record: estimate conservatively with JSON overhead. A record with 5 string fields and 3 integer fields: ~500 bytes in JSON (field names + values + delimiters). In binary (protobuf): ~50 bytes. Database row: ~100–200 bytes including row overhead and index entries.
Always separate text data from media data. Text is cheap — 1 billion tweet records at 300 bytes each = 300 GB. Media is expensive — 1 billion photos at 3 MB each = 3 PB. Handle them with different architectures: text in a relational or column-store database; media in object storage (S3) with a CDN.
Bandwidth = QPS × average_response_size
Average response size: a JSON API response is 1–10 KB. A web page: 100 KB–1 MB. A 4K video chunk (2-second segment): ~10 MB. Check whether your calculated bandwidth exceeds common link capacities: datacenter uplink (10 Gbps = 1.25 GB/second), CDN edge bandwidth (typically in Tbps for large CDNs).
Given: 300M MAU, Twitter-like social network. Design the tweet posting and reading flow.
DAU: 300M MAU × 40% engagement = 120M DAU (Twitter's reported ratio).
Write QPS: 120M DAU. Assume 1% of DAU post a tweet per day = 1.2M tweets/day. 1.2M / 86,400 = ~14 write QPS. Peak: 14 × 3 = ~42 write QPS. Very low — a single database shard handles this easily.
Read QPS: 120M DAU × 100 timeline reads/day / 86,400 = ~139,000 read QPS average. Peak: ~420,000 read QPS. This is the design-driving number — reads are 10,000× more common than writes. Timeline reads must be served from cache.
Fan-out writes: average Twitter user has 200 followers. 1.2M tweets/day × 200 fan-out = 240M fan-out writes/day = ~2,800 fan-out writes/second. This is the bottleneck in the write path — not the original tweet write, but the fan-out to all followers' timelines.
Storage: 1.2M tweets/day × 300 bytes = 360 MB/day. 10 years = ~1.3 TB of tweet text. Trivial. Media (photos, videos) attached to tweets: assume 20% of tweets have media, average 3 MB each = 1.2M × 0.2 × 3 MB = 720 GB/day = ~260 TB/year. Media dominates storage — requires object storage (S3) and CDN.
Conclusion: Write path is simple (14 write QPS). Read path requires aggressive caching (420K peak QPS). Fan-out writes at 2,800/second need a queue-based fan-out architecture (pre-computed timelines). Media storage requires separate object storage and CDN.
Given: 100M URLs shortened per day, 10:1 read ratio.
Write QPS: 100M / 86,400 = ~1,160 writes/second. Peak: ~3,500 writes/second.
Read QPS: 100M × 10 / 86,400 = ~11,600 reads/second. Peak: ~35,000 reads/second.
Storage: URL record: ~500 bytes (short URL + original URL + metadata). 100M/day × 500 bytes = 50 GB/day. 10 years: 50 GB × 3,650 = 182 TB. Fits on a single large SSD cluster with sharding. Cache: at 35,000 read QPS with Zipf distribution (top 20% URLs receive 80% of traffic), cache hit rate of ~80% means only 7,000 cache misses/second — well within single PostgreSQL instance capacity.
Conclusion: Storage is manageable (182 TB over 10 years with sharding). Reads are cache-dominated — Redis with base62-encoded keys handles the hot path. Writes to PostgreSQL with a simple sequential ID scheme (base62 encoding of auto-increment ID).
What are the key latency numbers every engineer should know?
L1 cache: 1ns. RAM: 100ns. SSD: 150µs. Same-datacenter network: 0.5ms. HDD: 10ms. Cross-region: 40ms. US-Europe: 150ms. Key ratios: RAM is 1000× faster than SSD, SSD is 1000× faster than HDD, in-datacenter is 300× faster than cross-Atlantic.
How do you estimate QPS?
DAU × actions/user/day / 86,400. Peak = average × 3. Read/write ratio: 100:1 for social feeds, 10:1 for more balanced apps. Always design for peak QPS.
How do you estimate storage requirements?
Records/day × bytes/record × retention days. Separate text (cheap, ~300 bytes/record) from media (expensive, MB–GB per item). Media dominates — handle with object storage + CDN, not databases.
How do you estimate bandwidth requirements?
QPS × average response size. Check against link capacities (10 Gbps datacenter uplink = 1.25 GB/sec). Video streaming at scale requires CDN — a single datacenter cannot serve Tbps of video traffic.
Practice designs in SysSimulator → Interview framework guide