Design Fundamentals • Back-of-the-envelope CalculationsEasy⏱️ ~3 min
What are Back of the Envelope Calculations and Why Do They Matter?
Back of the envelope calculations are rapid order of magnitude estimates that transform product requirements into concrete resource numbers. Rather than building a detailed capacity plan, these calculations answer whether a design is fundamentally viable and identify where constraints will emerge first. The process converts business inputs like daily active users, session duration, and media sizes into per second loads, storage growth, and tier specific capacity needs. For example, knowing that 1 million events per day translates to roughly 12 per second gives immediate insight into whether a single database instance can handle the write load.
The core value lies in speed and elimination of infeasible designs before significant engineering investment. When evaluating whether to precompute social feeds or compute them on demand, a quick calculation showing that 1 million posts per day with 500 followers each generates 500 million feed insertions per day (approximately 5,800 per second average, potentially 29,000 per second at peak) immediately reveals write amplification costs. This helps teams choose architectures based on real constraints rather than intuition. The method deliberately ignores fine details to focus on first order effects: peak request rates, data volumes, hot versus cold access patterns, and replication overhead.
Production systems at scale routinely use these estimates during design reviews and capacity planning. Netflix engineers calculating streaming bandwidth for 100,000 concurrent viewers watching 1080p video at 5 Mbps quickly arrive at 600 Gbps egress and 270 TB per hour, which directly informs CDN architecture and peering decisions. Facebook historically used back of the envelope math to size web server tiers, estimating that instances handling 5,000 to 10,000 lightweight requests per second at sub 50ms latency would require 20 to 40 instances for 200,000 RPS peak load, plus headroom for failures. The calculations are not precise predictions but sanity checks that keep designs grounded in physical reality.
💡 Key Takeaways
•Converts product metrics (DAU, session duration, objects per user) into concrete per second loads and storage requirements using simple ratios like 1 million per day equals approximately 12 per second
•Focuses on order of magnitude estimates rather than precision, deliberately ignoring fine details to identify first order constraints like peak QPS, data volumes, and replication overhead
•Netflix example: 100,000 concurrent 1080p streams at 5 Mbps requires 600 Gbps egress and 270 TB per hour, directly informing CDN and peering architecture decisions
•WhatsApp processes over 100 billion messages per day (1.16 million per second average) with peak loads 3 to 5 times higher during regional spikes, requiring capacity planning for 3 to 6 million messages per second
•Primary purpose is rapid elimination of infeasible designs before engineering investment, not replacement for load testing or precise capacity models
•Facebook fan out calculations show 1 million posts per day with 500 followers each generates 500 million feed insertions daily (5,800 per second average, 29,000 per second peak), exposing write amplification costs
📌 Examples
YouTube receives 500 hours of video uploads per minute. At 5 Mbps encoding (1080p compressed), that is 0.625 MB per second or 2.25 GB per hour. Daily ingest becomes 720,000 hours per day times 2.25 GB per hour, equaling 1.62 PB per day. With 3x replication, net growth is approximately 4.9 PB per day before considering multiple adaptive bitrate renditions.
A social media feed with 1 million posts per day reaching 500 followers each (push model) generates 500 million feed insertions per day. At 150 bytes per entry (IDs, timestamps, pointers), raw storage is 75 GB per day. With 3x replication, that becomes 225 GB per day or 82 TB per year just for feed indices.
For a service with 10 million DAU, average session of 30 minutes, and 20 API calls per session, total daily calls are 200 million. This translates to 2,315 calls per second on average. With a 5x peak factor for time of day patterns, peak load reaches 11,575 calls per second, informing web tier instance counts.