Requirements, Traffic Estimation, and Capacity Planning
Learn to convert product requirements into approximate requests per second, storage growth, bandwidth, and capacity targets.
Clarify Scope and Model the Workload
Before calculating infrastructure, define the workload. Identify users, read/write ratio, peak-to-average traffic, payload sizes, geographic distribution, burstiness, and data-retention requirements. Ask whether requests are interactive, batch, streaming, or background jobs.
For a photo-sharing application, the home feed may be read-heavy while uploads are write-heavy. A single average request rate hides these differences. Estimate each important operation separately: feed reads, image uploads, comments, notifications, and search queries.
Use explicit assumptions and label estimates as estimates. If 2 million daily active users each open the feed 20 times a day, that is 40 million feed reads per day. Divide by 86,400 seconds for an average rate, then apply a peak factor to approximate peak load. Real traffic is not uniform, so load testing and production metrics must eventually replace assumptions.
const dailyActiveUsers = 2_000_000;
const feedOpensPerUser = 20;
const secondsPerDay = 86_400;
const dailyFeedReads = dailyActiveUsers * feedOpensPerUser;
const averageRps = dailyFeedReads / secondsPerDay;
const peakFactor = 5;
const estimatedPeakRps = averageRps * peakFactor;
console.log({ dailyFeedReads, averageRps, estimatedPeakRps });- Estimate each operation class independently.
- State assumptions and use ranges when inputs are uncertain.
- Average RPS is not peak RPS.
A service handles 8,640,000 requests per day. What is its approximate average request rate?
Estimate Storage, Bandwidth, and Memory
Storage estimation begins with record count, average encoded record size, indexes, replication, and retention. If 10 million events are written daily and each stored event averages 700 bytes, raw event payload growth is roughly 7 GB/day before indexes, replication, compression, and metadata. Over a year, that is about 2.56 TB of raw payload.
Bandwidth is request rate multiplied by average payload size. At 2,000 responses/second and 40 KB per response, outbound payload traffic is about 80 MB/s before protocol overhead and retransmissions. Distinguish ingress from egress and consider media separately from metadata.
Memory estimates are especially important for caches and indexes. A cache entry's real cost includes key/value bytes plus object and allocator overhead. Never assume a 100-byte logical record consumes exactly 100 bytes in RAM. Use representative measurements and leave headroom for bursts and runtime overhead.
records/day × average bytes/recordrequests/second × average payload bytesdaily growth × retention days- Include indexes and replicas in storage planning.
- Separate payload traffic from request counts.
- Measure actual serialized sizes and cache overhead.
Headroom, Growth, and Capacity Safety Margins
Capacity planning should account for expected growth, peak traffic, failover, and uneven distribution. If a cluster needs 8 nodes at normal peak, ask whether it can tolerate one node failing and still meet its latency target. Capacity that exists only when every component is healthy is fragile.
Use a target utilization below 100% so the system has room for bursts, garbage collection, maintenance, and rebalancing. The appropriate threshold depends on workload: CPU-bound stateless APIs and latency-sensitive databases have different safe operating ranges.
Plan with scenarios: current load, expected growth, a promotional spike, loss of one availability zone, and recovery after an outage. Capacity planning is iterative; monitor real demand and update estimates rather than treating an early spreadsheet as truth.
Peak factors, replication factors, and failover headroom represent different effects. State what each factor means to avoid double-counting or understating capacity.
- Plan for component loss, not just healthy-state traffic.
- Keep measurable headroom for spikes and maintenance.
- Revisit estimates when real telemetry becomes available.