A photo-sharing service has 2 million new photo uploads per day, each stored as an original file averaging 3 MB plus two generated thumbnails averaging 200 KB combined, and everything is kept for 5 years with 3x replication for durability. How would you estimate the total storage the service needs to provision?

## What makes storage different from QPS Storage capacity estimation follows the same 'multiply the pieces together' discipline as QPS estimation, but the pieces are different: instead of a rate over time you're accumulating a growing total, and instead of one multiplier (peak factor) you typically apply two or three (replication factor, metadata/overhead, and a growth curve). The goal in an interview is not decimal precision - it's demonstrating that you know which multiplicative factors exist and can chain them in the right order without dropping one. ## The chain, one factor at a time 1. **Start with the atomic unit**: what does a single business event (here, one photo upload) actually write to storage? It's rarely just the file the user thinks they're uploading - a photo service typically also generates and stores derived assets, in this case two thumbnails at different sizes, so the real per-event footprint is the sum of every artifact created: `3 MB` original + `0.2 MB` thumbnails = `3.2 MB` per upload. Missing the derived assets is one of the most common estimation errors, because interview prompts often mention only the primary object and expect the candidate to think through what a real system generates around it (thumbnails, video transcodes, search index entries, audit logs). 2. **Next, convert the per-event size into a daily ingest rate** by multiplying by daily volume: `2,000,000` uploads/day x `3.2 MB` = `6,400,000 MB/day`, or `6.4 TB/day`. This is the 'flow' - how fast new data arrives. 3. **Storage estimation then needs to convert flow into a 'stock'** - the total accumulated over the retention window - by multiplying by the number of days data is kept: `6.4 TB/day` x `~1,825` days (5 years) `~= 11.7 PB`. This step is conceptually different from QPS estimation, where you only ever cared about the instantaneous rate; here the rate accumulates because storage, unlike compute, is a durable resource that keeps everything you've ever written until it's explicitly deleted or expires. ## The durability multiplier On top of the raw accumulated size, real systems apply a **durability multiplier**: data is never stored as a single copy, because a single disk or node failure would mean permanent data loss. - **Common replication factors are 3x** (e.g., HDFS's default, or triplicated storage across availability zones). - **Erasure-coding schemes** trade some replication overhead for space efficiency (roughly 1.4-1.5x instead of 3x, at the cost of more complex/slower reconstruction on failure). Applying 3x to `11.7 PB` gives roughly `35 PB` of physical storage that must actually be provisioned - three times the naive raw total, which is exactly the kind of factor that, if forgotten, makes an estimate look deceptively cheap. ## The trade-offs at every layer The trade-offs sit at every layer of this chain. - **Replication factor** trades raw storage cost against durability and read availability (more replicas also means more nodes that can serve reads, which helps QPS, but costs proportionally more disk and network for writes to stay in sync). - **Retention period** trades storage cost against product/legal requirements - a photo service might offer 'keep forever' as a feature, while a logging system might aggressively expire data after 30-90 days specifically to keep storage costs bounded; the retention window is often a product decision disguised as an engineering constraint, and a senior engineer should push back on unstated retention assumptions rather than accept '5 years' passively. - **There's also a hidden linear-growth assumption** in the calculation above: it treats daily ingest as constant for all 5 years, when in reality a growing product sees increasing daily uploads over time, so a flat multiplication understates the true multi-year total; a more rigorous estimate would model a growth curve (e.g., 20% year-over-year) and sum a series rather than multiply a constant. ## The failure mode The failure mode this estimation guards against is capacity planning that only accounts for compute and forgets that storage, unlike a CPU or a cache, never naturally sheds old data - a service that under-provisions storage doesn't degrade gracefully the way an overloaded API might; it hits a hard wall where writes start failing outright once disks fill up, which is a much more catastrophic outage than elevated latency. ## Logical bytes against physical bytes A well-known real-world analog is any large-scale object store like Amazon S3 or a company's internal blob store team, whose capacity planning explicitly separates 'logical bytes stored' from 'physical bytes provisioned' precisely because of the replication/erasure-coding multiplier, and who model growth curves rather than flat run-rates specifically because linear extrapolation reliably under-forecasts a growing product's actual storage bill.