Estimate only what can change the design#
Interview estimation is a decision tool. It can tell you whether one service is plausible, whether storage dominates the system, whether an origin survives cache misses, or whether bandwidth changes delivery. It is not a memory test for arbitrary scale tables.
Traffic: average is a baseline, peak sizes the path#
Average RPS = requests per day ÷ 86,400From daily users to peak reads
100M × 10 = 1B reads/day
1B ÷ 86,400 ≈ 11,600 reads/sec average
11,600 × 5 ≈ 58K peak RPSThe 5× factor is an assumption for this example, not a universal rule. Peak traffic is more useful than the daily average when checking whether the request path has enough capacity.
Traffic estimator
Approximate interview math. Change the inputs, then ask whether the result changes the architecture.
Read/write ratio: identify where pressure lands#
100M reads/day ÷ 10M writes/day ≈ 10:1A 10:1 ratio asks whether the read path would benefit from reusable results or additional read capacity, while the write path may remain the correctness bottleneck. The number does not automatically justify a cache or read replicas.
Storage: include time, then challenge the overheads#
One year of media objects
10M × 2 MB ≈ 20 TB/day
20 TB × 365 ≈ 7.3 PB/yearThat is raw object data using decimal units. A real plan must ask about metadata, indexes, compression, retention, deletion, backups, and the storage system's replication or coding model. Do not blindly multiply by a replication factor.
Bandwidth: payload size can dominate request count#
Outbound media traffic
50,000 × 500 KB ≈ 25 GB/sec outboundLarge payloads make media systems bandwidth-heavy even when request handling is straightforward. This is where content delivery and geographically distributed serving can materially change origin load and user latency.
Cache sizing: raw values are only the start#
A frequently accessed object set
20M × 1 KB ≈ 20 GB raw dataKeys, metadata, data structures, allocator fragmentation, replication, and operational headroom all consume capacity. This result does not mean a 20 GB cache instance is sufficient.
Cache hit rate: estimate the failure cliff#
100K requests/sec × 5% miss rate ≈ 5K requests/sec to storageAt a 95% hit rate, the backing store sees roughly 5K RPS. If the cache disappears, can it survive the jump toward 100K? The useful result is not the hit-rate percentage; it is the failure question the number exposes.
Concurrency: rate multiplied by time#
Concurrent operations ≈ arrival rate × average operation duration20K requests/sec × 0.2 sec ≈ 4,000 concurrent requestsIf requests arrive at 20K per second and each remains active for about 200 ms, roughly 4K are in flight at once. This can expose connection, worker, and memory pressure without turning the discussion into queueing theory.
Compact estimation cheat sheet#
1 day = 86,400 seconds
Average RPS = requests/day ÷ 86,400
Storage = new objects × average size × retention
Bandwidth = requests/sec × average payload size
Cache backend load = total request rate × cache miss rate
Approx. concurrency = arrival rate × operation duration- False precision: prefer
~60K RPSto57,823.43 RPS. - Estimating everything: skip storage arithmetic when storage cannot affect the answer.
- Ignoring peaks: averages hide burst and provisioning requirements.
- Disconnected numbers: every meaningful result should test an architecture choice.
- Assumptions presented as facts: label traffic, peak, size, and retention inputs.
Related practice problems
Use the manifest-backed prompts below to apply this lesson in a complete design.
- Service Level ObjectivesGoogle Site Reliability Engineering