How do you estimate storage needs in a back-of-envelope calculation?
Storage estimation follows a data-type decomposition:
**Step 1: Identify what gets stored** Break the system into data types: user records, messages, images, videos, metadata. Each has a different size profile.
**Step 2: Estimate size per object** Use standard benchmarks: - Text record (user profile, tweet): 1 KB - Image (compressed, thumbnail): 100–300 KB; full-size: 1–5 MB - Video (1 min, compressed): 50–100 MB; 1 hr HD: 1–2 GB - Audio (1 min MP3): 1 MB
**Step 3: Estimate volume per day** For a Twitter-like system with 150M DAU and 0.1 tweets/user/day: - 15M tweets/day × 1 KB = 15 GB/day text - 30% include an image (4.5M images/day × 200 KB = 900 GB/day)
**Step 4: Project over the design horizon** Interviewers typically want 5 years. 5 years ≈ 1,800 days. - Text: 15 GB/day × 1,800 = 27 TB - Images: 900 GB/day × 1,800 = 1.6 PB
**Step 5: Add replication overhead** Data is typically stored with 3× replication (HDFS default, S3 default). Multiply total by 3.
**Step 6: State which tier** - Hot storage (SSD): recent data, frequently accessed - Warm storage (HDD/object store): older data - Cold storage (Glacier, tape): archival
**Key powers of 2**: 10 KB × 10^6 objects = 10 GB; 1 MB × 10^9 = 1 PB. Memorizing these conversions prevents arithmetic errors under pressure.
Interviewers want to see: explicit per-object size assumptions, separation of data types, replication factor, and a growth rate.
Correctly breaks storage by type, uses reasonable size estimates, and projects over a 5-year horizon.
Accounts for replication factor, separates storage tiers, and connects storage volume to architectural choices (object store vs relational DB).
Reading the answer is step one. Explaining it unprompted — under interview pressure — is what actually matters. Get AI-graded feedback on your answer with follow-up probes on your weak points.
Get Graded — Free Assessment