Why choosing the right storage matters in HLD - Scalability Evidence

Scalability Analysis - Why choosing the right storage matters

Growth Table: Storage Needs at Different Scales

Users	Data Volume	Request Rate	Storage Type Impact
100 users	MBs to GBs	Low (few QPS)	Simple local disk or single DB instance works
10,000 users	GBs to TBs	Hundreds to thousands QPS	Need scalable DB, caching, and faster storage (SSD)
1,000,000 users	TBs to PBs	Thousands to tens of thousands QPS	Distributed storage, sharding, and tiered storage needed
100,000,000 users	PBs+	Hundreds of thousands QPS+	Highly distributed, multi-region storage with CDN and archival

First Bottleneck: Storage Performance and Scalability

At small scale, storage is simple and fast enough. As users and data grow, the storage system becomes the first bottleneck because:

• Disk I/O limits read/write speed.
• Single database instances can't handle high query rates.
• Storage capacity limits total data size.
• Latency increases with data size and complexity.

Choosing the right storage type early prevents slowdowns and outages as traffic grows.

Scaling Solutions for Storage

• Vertical scaling: Upgrade to faster disks (SSD, NVMe) and more RAM for caching.
• Horizontal scaling: Use database sharding to split data across servers.
• Caching: Add in-memory caches (Redis, Memcached) to reduce DB load.
• Tiered storage: Store hot data on fast storage, cold data on cheaper slower disks.
• Distributed storage: Use systems like Cassandra, HDFS for large scale data.
• Content Delivery Network (CDN): Offload static content to edge servers to reduce storage and bandwidth load.

Back-of-Envelope Cost Analysis

Example for 1 million users:

• Requests per second (QPS): ~10,000 (assuming 10 requests/user/hour)
• Storage needed: ~10 TB (assuming 10 KB data/user)
• Bandwidth: ~100 MB/s (assuming 10 KB/request)
• Single DB instance max QPS: ~5,000 → need at least 2 DB servers or sharding
• Disk IOPS: SSD can handle ~100,000 IOPS, enough for this scale

Interview Tip: Structuring Your Scalability Discussion

When asked about storage scalability:

1. Start by estimating data size and request rates at different user scales.
2. Identify the storage bottleneck (capacity, IOPS, latency).
3. Discuss vertical and horizontal scaling options.
4. Mention caching and tiered storage to optimize performance and cost.
5. Explain trade-offs and when to use distributed storage or CDNs.

Self Check Question

Your database handles 1000 QPS. Traffic grows 10x to 10,000 QPS. What do you do first and why?

Key Result

Choosing the right storage early is critical because storage performance and capacity become the first bottleneck as user count and data volume grow. Proper scaling strategies like sharding, caching, and tiered storage prevent slowdowns and outages.

Practice

1. Why is it important to choose the right storage type for a system?

easy

A. Because storage type changes the programming language used

B. Because it affects data safety and system performance

C. Because storage type determines the user interface design

D. Because storage type controls the network bandwidth

Solution

1. Step 1: Understand the role of storage in a system

   Storage holds data, so its choice impacts how safe and fast data access is.

2. Step 2: Connect storage choice to system outcomes

   Choosing the right storage ensures data is protected and system runs efficiently.

3. Final Answer:

   Because it affects data safety and system performance -> Option B

4. Quick Check:

   Storage choice = data safety and speed [OK]

Hint: Storage choice impacts data safety and speed [OK]

Common Mistakes:

• Confusing storage with programming language
• Thinking storage affects UI design
• Assuming storage controls network bandwidth

2. Which of the following storage types is best suited for fast read and write operations in a caching system?

easy

A. Cold storage like tape drives

B. Magnetic hard drives only

C. In-memory storage like RAM

D. Optical storage like CDs

Solution

1. Step 1: Identify storage needs for caching

   Caching requires very fast read and write speeds to improve performance.

2. Step 2: Match storage type to speed requirements

   RAM is the fastest storage type suitable for caching compared to others listed.

3. Final Answer:

   In-memory storage like RAM -> Option C

4. Quick Check:

   Fast cache = RAM [OK]

Hint: Cache needs fastest storage: choose RAM [OK]

Common Mistakes:

• Choosing slow storage like tape or optical for caching
• Ignoring speed differences between storage types
• Assuming magnetic drives are fastest

3. Consider a system that stores user photos and metadata. Which storage combination best balances cost and performance?

medium

A. Store photos in tape drives and metadata in in-memory storage

B. Store photos and metadata both in relational database

C. Store photos in in-memory storage and metadata in flat files

D. Store photos in object storage and metadata in a relational database

Solution

1. Step 1: Analyze storage needs for photos and metadata

   Photos are large files suited for object storage; metadata is structured data suited for databases.

2. Step 2: Evaluate cost and performance trade-offs

   Object storage is cost-effective for large files; relational DB offers fast queries for metadata.

3. Final Answer:

   Store photos in object storage and metadata in a relational database -> Option D

4. Quick Check:

   Photos = object storage, Metadata = DB [OK]

Hint: Large files in object storage, metadata in DB [OK]

Common Mistakes:

• Storing large files in relational DB (costly and slow)
• Using in-memory for large photos (expensive, volatile)
• Using tape drives for active data (slow access)

4. A system uses a NoSQL database for all data storage but faces slow complex queries. What is the likely cause?

medium

A. NoSQL databases are not optimized for complex relational queries

B. NoSQL databases always have slow writes

C. NoSQL databases cannot store large data

D. NoSQL databases require more network bandwidth

Solution

1. Step 1: Understand NoSQL database strengths and weaknesses

   NoSQL excels at flexible, scalable storage but is not optimized for complex joins or relational queries.

2. Step 2: Identify cause of slow complex queries

   Using NoSQL for relational queries causes slow performance due to lack of join optimizations.

3. Final Answer:

   NoSQL databases are not optimized for complex relational queries -> Option A

4. Quick Check:

   NoSQL + complex queries = slow [OK]

Hint: NoSQL is weak for complex joins [OK]

Common Mistakes:

• Assuming NoSQL is slow for all operations
• Thinking NoSQL can't store large data
• Blaming network bandwidth for query slowness

5. You are designing a system expected to handle millions of user transactions daily with strict latency requirements. Which storage strategy best fits this scenario?

hard

A. Use distributed in-memory cache for active data and persistent NoSQL for durability

B. Use a single relational database for all transactions

C. Store all data on slow cold storage to save cost

D. Use flat files on local disk for all transaction data

Solution

1. Step 1: Analyze system requirements for high volume and low latency

   Millions of transactions require fast access and scalable storage to meet latency needs.

2. Step 2: Choose storage types that balance speed and durability

   Distributed in-memory cache offers fast access; NoSQL provides scalable, durable storage for persistence.

3. Step 3: Evaluate other options for suitability

   Single DB may bottleneck; cold storage is too slow; flat files lack scalability and reliability.

4. Final Answer:

   Use distributed in-memory cache for active data and persistent NoSQL for durability -> Option A

5. Quick Check:

   High volume + low latency = cache + NoSQL [OK]

Hint: Combine fast cache with durable NoSQL storage [OK]

Common Mistakes:

• Relying on single DB for high load
• Using slow cold storage for active data
• Storing transactions in flat files