Estimation in interviews isn't about precision. It's about arriving at a number that drives a design decision within 2-3 minutes.
Every estimation follows the same 3-step formula: Users β Actions β Resources. Start from DAU, convert to requests/second, then compute storage and bandwidth.
Memorize the infrastructure ceilings: single PostgreSQL ~10K reads/sec, single Redis ~100K ops/sec, single app server ~1K-10K req/sec depending on request profile. When your traffic exceeds a ceiling, you need the next scaling strategy.
The read-to-write ratio is the single most important number in any estimation. It determines whether you need a cache, read replicas, or neither.
Round aggressively. 86,400 seconds in a day? Use 100,000. It's close, and the mental math is instant. Your interviewer cares that you know which numbers matter, not that you can divide by 86,400.
You're designing a URL shortener. Your teammate says: "Let's shard the database." But the system only handles 100 writes per second. A single PostgreSQL instance handles 10,000 writes per second. You've just added sharding complexity for no reason.
This is what happens without estimation. Engineers reach for sophisticated solutions because they sound impressive, not because the math demands them. Estimation is the filter that prevents your design from being either too simple (under-provisioned) or too complex (over-engineered).
I've seen candidates add Kafka, Redis, Cassandra, and a CDN to a system that processes 500 requests per second. That's a single Express.js server's workload. The interviewer's internal reaction: "This person will over-engineer everything they touch."
For your interview: estimation isn't a performance you put on. It's a tool that makes your design decisions defensible. When the interviewer asks "Why did you add a cache?", you say: "Because our read traffic is 500K/sec and a single database handles 10K reads/sec. Even with 5 read replicas, we're at 50K/sec. The cache absorbs the remaining 450K reads/sec at sub-millisecond latency." That's the difference between a hand-wavy design and an engineered one.
The number one mistake in estimation: spending 10 minutes on arithmetic. The interviewer doesn't care if your storage calculation is 4.2 TB or 5.1 TB. They care that you identified storage as a concern and arrived at "roughly 5 TB over 5 years." Round early, round aggressively, and spend your time on the design decisions the numbers enable.
These are the constants of system design. Memorize them the way a pilot memorizes V-speeds. You'll use them in every interview.
Your estimation reference card. The infrastructure ceilings (middle column) are the numbers that drive design decisions: when traffic exceeds a ceiling, you need the next scaling tier.
The key insight: every layer jump is roughly 10-100x slower. RAM to SSD: ~1,500x. SSD to HDD: ~67x. Local to cross-continent: ~300x. This is why caches exist at every layer.
I keep this table in my head during every design. When my estimated traffic for a component exceeds its ceiling, that's when I introduce the next scaling technique. Not before. This prevents over-engineering.
That 500:1 ratio immediately tells you: this is a read-heavy system. Your primary scaling concern is reads, not writes. A cache layer will have massive impact.
At 1 PB, you're in object storage territory (S3). No relational database holds this. This estimate just drove a design decision: photos go in S3, metadata goes in the database.
That's 2.5 Gbps, which is significant. This justifies a CDN: serving 2.5 GB/sec from origin servers is expensive and slow for global users. A CDN absorbs 90%+ of this.
Five lines of math that justify five architectural decisions. That's the power of estimation.
Interview tip: connect every number to a decision
Never compute a number without immediately stating what it means for the design. "5,000 reads/sec" by itself is trivia. "5,000 reads/sec, which means a single PostgreSQL instance can handle it but we'd want a cache for sub-ms latency" is engineering.
Read:Write = 1:1 (every message is written once, read by recipients)
Messages/day: DAU Γ 40-100 messages per user
Key insight: connection management (WebSockets) is the bottleneck
Design implication: state management for millions of persistent connections
Read:Write = 100:1 (browsing vs buying)
Order conversion: 2-5% of sessions
Key insight: cart and checkout are write-heavy but low-volume; catalog is read-heavy high-volume
Design implication: separate scaling strategies for catalog (cache) vs orders (ACID DB)
Estimation is a tool, not a standalone phase. Pull it out during Phase 2 (Non-Functional Requirements) to set scale targets, and during Phase 5 (High-Level Architecture) to justify component choices. The numbers from estimation inform every infrastructure decision.
Show the chain: DAU β actions β requests/sec. Clear, reproducible.
"What if traffic is 10x higher?"
"At 10x, our 5K reads/sec becomes 50K. The cache still handles it (Redis does 100K ops/sec). The DB is now 500 reads/sec on misses, still fine. The bottleneck shifts to bandwidth: 25 GB/sec needs a CDN with multiple edge PoPs."
"Is that storage estimate realistic?"
"It's order-of-magnitude correct. In production I'd add 30% overhead for indexes, replicas, and tombstones. But for design purposes, '5 TB' vs '6.5 TB' doesn't change the architecture."
Interview tip: say your rounding out loud
When you round 86,400 to 100,000 or 2.6M to 3M, say it: "I'm rounding up to keep the math simple. The error is under 15% and won't affect the architecture." This signals mathematical literacy and pragmatism. Both are positive signals.
Every estimation follows three steps: traffic (users to req/sec), storage (size Γ volume Γ time), bandwidth (req/sec Γ payload size).
Memorize infrastructure ceilings: PostgreSQL 10K reads, Redis 100K ops, app server 1-10K req/sec depending on request profile. These are the decision thresholds.
Always split read and write traffic. The ratio drives your entire architecture.
Round aggressively (86,400 β 100K) and say it out loud. Precision is a waste of interview time.
Connect every number to a design decision. An estimate without a consequence is decoration.
Peak traffic is 3-10x average. Design for peak, size infrastructure for average with auto-scaling.
For video/media platforms, bandwidth is the primary cost driver, not storage. For text platforms, storage and compute dominate.
Approach & Structure - The 6-phase framework that estimation plugs into. Use estimation inside Phase 2 (NFRs) and Phase 5 (Architecture) to justify decisions with numbers.
Capacity Planning - Takes your estimates and translates them into infrastructure decisions: server counts, shard counts, replica counts.
Scalability - The concept your estimates are sizing for. Understanding vertical vs. horizontal scaling determines which ceiling matters.
Caching - The first component justified by estimation. When reads exceed DB capacity, caching is the answer.
Databases - Understanding database throughput ceilings is half of the estimation skill.
