# System Design Interviews: How to Defend Storage Cost vs Performance Trade-offs ![System design diagram](https://bugfree-s3.s3.amazonaws.com/mermaid_diagrams/image_1771524963458.png "Storage vs Performance"){:width="800px"} > In system design interviews you won't just pick a component — you'll justify why you picked it. The most common justification centers on storage: how much are you willing to spend to get the latency, throughput, and durability you need? This guide gives a clear, repeatable structure to defend storage cost vs performance trade-offs during interviews, with practical examples, formulas, and interview phrasing. --- ## 1) Start by clarifying the use case and SLOs Ask targeted questions to turn vague requirements into measurable goals. Focus on: - Latency SLOs (p99, p95, median) — e.g., "read latency < 50 ms p95". - Throughput (requests/sec or MB/sec). - Durability/availability requirements (RPO/RTO, replication factor). - Access patterns (read-heavy, write-heavy, hot vs cold data). - Data growth and retention policies. Real-time systems pay for low latency. Batch systems can trade latency for lower cost. Always state the SLO you are optimizing for. --- ## 2) Compare the storage options (short pros/cons) - In-memory (RAM) - Pros: Lowest latency, highest throughput. - Cons: Highest cost per GB, volatile (unless backed), limited capacity. - Use when: sub-ms or single-digit ms latency is mandatory for hot working set. - SSD (NVMe / provisioned IOPS) - Pros: Low latency (ms), good random IOPS. - Cons: Higher cost than HDD; can still be more expensive under heavy write amplification. - Use when: low read/write latency is needed for large datasets. - HDD - Pros: Lowest cost per GB for sequential workloads. - Cons: Much higher random-access latency. - Use when: cold storage, large sequential scans, or strict budget constraints. - Managed cloud tiering (hot/warm/cold) - Pros: Cost-effective by matching access patterns to storage tiers. - Cons: Complexity, egress costs when thawing cold data. Always map an option back to the SLO and access pattern. --- ## 3) Call out hidden & operational costs Don't forget these when you justify a trade-off: - Replication and backups: multiply raw data by replication factor. Example: total_bytes = data_bytes * (replication_factor + backup_factor). - Network egress: data reads across regions or external clients can add per-GB costs. - Indexes and metadata: indices can add 10–50% extra storage depending on schema. - Compression: reduces storage but adds CPU/latency on access. - Write amplification / compaction: increases effective storage and I/O. - Monitoring, snapshot retention, and archived logs. - Operational overhead: more hardware types or tiers increases operational complexity and personnel cost. --- ## 4) Show practical optimizations and where they fit - Caching: place a cache (L1/L2) in front to reduce hot read pressure on durable storage. - Load balancing & sharding: distribute load to lower per-node latency and cost per request. - Indexing and schema design: choose indexes that reduce I/O for the most common queries. - Compression & columnar formats: great for cold analytics workloads; watch CPU latency impact. - Tiering & lifecycle policies: move data to cheaper tiers when it becomes cold. --- ## 5) Always quantify your trade-offs — use simple math Interviewers expect numbers. Use clear formulas and a short worked example. Key formulas: - Storage cost = data_size_GB * replication_factor * cost_per_GB_month - Effective request cost = requests_per_month * cost_per_request - Cache hit reduction: requests_to_storage = total_requests * (1 - cache_hit_rate) Example (hypothetical numbers): - Raw data: 10 TB = 10,000 GB - Replication factor: 3 => stored bytes = 30,000 GB - Storage price (SSD): $0.10/GB/month => storage cost = 30,000 * $0.10 = $3,000/month - Move to HDD at $0.03/GB/month => cost = 30,000 * $0.03 = $900/month - Trade-off: save $2,100/month but expect higher median read latency (e.g., +20–50 ms) and slower random reads. If you add a cache that reduces storage reads by 80%, you can justify using cheaper storage behind the cache because effective latency for most reads stays low while the bill drops. For CPU cost from compression: if compression adds 0.5 ms extra CPU per request and you have 1M requests/day, that's 500k ms extra CPU = ~139 CPU-hours/day. Translate CPU-hours to $ using your cloud's pricing to show the dollar impact. --- ## 6) Explain how the choice scales with data growth Use formulas and projections. For example: - Year-1 data: 10 TB; Year-2 growth: 3x => 30 TB - If replication=3 and storage=$0.10/GB: cost grows from $3k/month to $9k/month. Point out thresholds where your architecture should change: - At X TB, SSD costs dominate — consider tiering. - At Y IOPS, a single shard can’t handle throughput — plan sharding. Show that your decision isn't just for now but for the next 6–24 months. --- ## 7) Interview-friendly script (how to present it) - Clarify: "Can I confirm the SLOs? Are we optimizing for p95 latency < 50 ms and 10k req/s?" - Propose options: "We can use in-memory caching + SSD-backed store for hot data, and HDD cold tier for infrequently accessed data." - Quantify: "With 10 TB of raw data and replication=3, SSD costs us ~$3k/month vs HDD $900/month; adding a cache that handles 80% of reads reduces effective storage I/O by 80%, letting us move colder data to HDD while keeping p95 read latency under 50 ms for most requests." - Discuss scaling: "If data grows 3x, storage cost scales linearly — at that point we'd add tiering and more aggressive TTLs." - Close: "Given the SLOs and growth, I recommend X because it minimizes monthly cost while meeting the latency SLO for 95% of requests. If the product needs stricter p99 latency, we should move Y% of the working set to in-memory." --- ## 8) Quick checklist for interview answers - Did you ask about SLOs and access patterns? ✅ - Did you compare concrete storage options and why? ✅ - Did you include hidden costs and operational complexity? ✅ - Did you show simple math and projections? ✅ - Did you suggest optimizations and how the design evolves? ✅ --- Summary In system design interviews, don't treat storage vs performance as a black box. Ask questions, pick measurable SLOs, compare options, call out hidden costs, quantify with simple math, and explain how your choice scales. Saying "it's cheaper but slower" isn't enough — show exactly how much cheaper, how much slower, and why that's acceptable for the defined SLOs. Good luck — and remember: "$X more for Y ms less" is an interview-winning sentence when backed by clear numbers and scaling logic.