# System Design: Capacity Planning — Back-of-Envelope Calculations, Throughput, Latency, Bandwidth, Storage Estimation

Source: https://www.techinterview.org/post/3233474151/system-design-capacity-planning-performance-estimation-back-of-envelope-calculations-throughput-latency-bandwidth-storage/
Updated: 2026-04-20 · techinterview.org

Capacity planning and back-of-envelope estimation are essential skills for system design interviews. Every design decision -- whether to use a single database or a sharded cluster, whether caching is needed, whether async processing is required -- depends on the scale of the system. This guide provides the numbers, formulas, and techniques for making accurate capacity estimates under interview pressure.

## Numbers Every Engineer Should Know

Latency numbers (approximate): L1 cache reference: 1 ns. L2 cache reference: 4 ns. Main memory reference: 100 ns. SSD random read: 16 microseconds. HDD random read: 2 ms. Round trip within same datacenter: 0.5 ms. Round trip US East to West: 40 ms. Round trip US to Europe: 80 ms. Throughput numbers: a single PostgreSQL instance handles 5,000-50,000 simple queries/sec (depends on query complexity and hardware). Redis handles 100,000-300,000 operations/sec. Kafka handles 1-10 million messages/sec per cluster. A single web server handles 1,000-10,000 HTTP requests/sec. Storage numbers: 1 character = 1 byte (ASCII) or 2-4 bytes (UTF-8). 1 UUID = 16 bytes (binary) or 36 bytes (string). 1 timestamp = 8 bytes. A typical database row = 100-1000 bytes. A typical JSON API response = 1-10 KB. An image = 100 KB - 5 MB. One hour of video = 1-10 GB. Time conversions: 1 day = 86,400 seconds (round to 100,000). 1 month = 2.6 million seconds (round to 2.5 million). 1 year = 31.5 million seconds (round to 30 million).

## Traffic Estimation

Start with Daily Active Users (DAU) and work toward requests per second. Formula: requests_per_second = DAU * actions_per_user_per_day / seconds_per_day. Example: a social media app with 100 million DAU. Each user makes 20 requests per day (feed loads, likes, comments). Total: 100M * 20 / 86400 = 23,148 requests/sec. Round to 25,000 RPS. Peak traffic: typically 2-5x average. Peak = 25,000 * 3 = 75,000 RPS. Read/write ratio: most applications are read-heavy. A social feed is 90% reads, 10% writes. Reads: 22,500/sec. Writes: 2,500/sec. This tells you: 75,000 peak RPS requires multiple application servers behind a load balancer (one server handles ~5,000-10,000 RPS). 2,500 writes/sec is within a single database capability, but a caching layer is needed for 22,500 reads/sec. If the read ratio is higher (99:1 for a content platform), caching becomes even more critical. Always state your assumptions: "I assume 100M DAU with 20 requests per user per day, a 90:10 read-write ratio, and 3x peak factor."

## Storage Estimation

Estimate storage growth per day and project over the system lifetime (typically 5 years). Example: a URL shortener. Each URL record: short_url (7 bytes), original_url (average 100 bytes), created_at (8 bytes), user_id (8 bytes), click_count (4 bytes) = ~130 bytes per record. Round to 200 bytes (include index overhead and metadata). New URLs per day: 10 million. Daily storage: 10M * 200 bytes = 2 GB/day. Over 5 years: 2 GB * 365 * 5 = 3.65 TB. With 3x replication: ~11 TB. This fits on a single modern server (16 TB SSD) but may benefit from sharding for write throughput. For media-heavy applications: if users upload 1 million photos per day at 2 MB each, that is 2 TB/day = 730 TB/year. Object storage (S3) is required -- this does not fit on a single server. Database storage (metadata) is separate from object storage (media files). Always calculate both. Memory estimation for caching: if 20% of daily data is "hot" (Pareto principle), cache size = daily_unique_reads * average_size * 20%. For the URL shortener: 100M unique reads/day * 200 bytes * 20% = 4 GB cache. This fits in a single Redis instance.

## Bandwidth Estimation

Bandwidth = requests_per_second * average_response_size. Inbound (writes): 2,500 writes/sec * 200 bytes = 500 KB/sec = 4 Mbps. Negligible. Outbound (reads): 22,500 reads/sec * 200 bytes = 4.5 MB/sec = 36 Mbps. Moderate. For media-heavy applications: if each response includes a 2 MB image: 22,500 * 2 MB = 45 GB/sec. This is massive and requires a CDN -- the origin server cannot handle this directly. CDN cache hit rate of 95% reduces origin bandwidth to 45 GB * 5% = 2.25 GB/sec. Network capacity planning: a standard server NIC is 1 Gbps (125 MB/sec) or 10 Gbps (1.25 GB/sec). A 10 Gbps NIC saturates at approximately 10,000 responses/sec with 100 KB responses. Beyond that, multiple servers or a CDN are required. In system design interviews, bandwidth estimation is most useful for: determining if a CDN is needed (yes if outbound > 1 Gbps), sizing network infrastructure, and justifying media storage decisions (why not store images in the database -- because the bandwidth would saturate the database NIC).

## Putting It All Together: Estimation Template

Use this template for any system design estimation: (1) State assumptions: DAU, actions per user, read:write ratio, data size per record. (2) Traffic: daily_requests = DAU * actions. RPS = daily_requests / 86400. Peak RPS = RPS * 3. Read RPS and Write RPS from the ratio. (3) Storage: daily_storage = daily_writes * record_size. Total_storage = daily_storage * 365 * years. With replication multiplier. (4) Bandwidth: outbound = read_RPS * response_size. Inbound = write_RPS * request_size. (5) Cache: cache_size = daily_unique_reads * record_size * 20%. (6) Infrastructure implications: do we need a CDN? (outbound > 1 Gbps). Do we need a cache? (read RPS > single DB capacity). Do we need sharding? (storage > single server, or write RPS > single DB capacity). Do we need async processing? (write latency > user tolerance). Practice: do this estimation for 5-10 common system design questions (URL shortener, Twitter, Instagram, WhatsApp, Uber) until the math is automatic. In the interview, spend 3-5 minutes on estimation, show your work, and let the numbers guide your architecture decisions.