Why choosing the right storage matters in HLD - Design It to Understand It

Design: Storage Selection for Scalable Systems

Focus on selecting storage types and explaining their impact on system design. Out of scope: detailed implementation of storage engines or hardware specifics.

Functional Requirements

FR1: Store and retrieve data efficiently based on use case

FR2: Support different data types: structured, semi-structured, unstructured

FR3: Ensure data durability and availability

FR4: Handle expected read and write loads

FR5: Provide appropriate latency for user experience

FR6: Support data consistency needs

FR7: Allow scaling as data and traffic grow

Non-Functional Requirements

NFR1: System must handle up to 1 million requests per second

NFR2: Latency for read operations should be under 100ms p99

NFR3: Availability target of 99.9% uptime

NFR4: Data size expected to grow to multiple terabytes

NFR5: Budget constraints limit use of very expensive storage solutions

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

❓ Question 7

Key Components

Relational databases (e.g., PostgreSQL, MySQL)

NoSQL databases (e.g., MongoDB, Cassandra)

Key-value stores (e.g., Redis, DynamoDB)

Object storage (e.g., S3, Azure Blob Storage)

Caching layers

Backup and archival storage

Design Patterns

Caching to reduce latency

Sharding and partitioning for scaling

Replication for availability and durability

Eventual consistency vs strong consistency trade-offs

Data tiering based on access frequency

CQRS (Command Query Responsibility Segregation) for read/write optimization

Reference Architecture

Client
  |
  v
Load Balancer
  |
  v
Application Servers
  |
  +-----------------------------+
  |                             |
  v                             v
Cache Layer (Redis)          Primary Storage
  |                             |
  v                             v
Fast Key-Value Store       Relational DB / NoSQL DB
  |
  v
Object Storage (for files, backups)

Components

Load Balancer

Nginx / AWS ELB

Distributes incoming requests evenly to application servers

Application Servers

Node.js / Java / Python

Handles business logic and interacts with storage layers

Cache Layer

Redis / Memcached

Stores frequently accessed data to reduce latency and load on databases

Primary Storage

PostgreSQL / MongoDB / Cassandra

Stores main application data with appropriate consistency and query capabilities

Object Storage

Amazon S3 / Azure Blob Storage

Stores large unstructured data like files, images, backups

Request Flow

1. Client sends request to Load Balancer

2. Load Balancer forwards request to Application Server

3. Application Server checks Cache Layer for data

4. If cache hit, data returned immediately

5. If cache miss, Application Server queries Primary Storage

6. Primary Storage returns data to Application Server

7. Application Server updates Cache Layer with fresh data

8. For large files or backups, Application Server interacts with Object Storage

9. Application Server sends response back to Client

Database Schema

Entities depend on use case but generally include: - User (id, name, email, created_at) - Product (id, name, description, price, created_at) - Order (id, user_id, product_id, quantity, status, created_at) Relationships: - User 1:N Order - Product 1:N Order Storage choice affects schema design, e.g., relational tables for structured data, document collections for flexible schemas.

Scaling Discussion

Bottlenecks

Database write throughput limits

Cache size and eviction policies

Load balancer capacity

Network bandwidth for large object storage

Data consistency delays in distributed storage

Solutions

Implement database sharding and partitioning to distribute load

Use cache eviction strategies and scale cache clusters horizontally

Deploy multiple load balancers with health checks and failover

Use CDN and multipart upload for large files to optimize bandwidth

Choose appropriate consistency models and use replication carefully

Interview Tips

Time: Spend 10 minutes understanding requirements and constraints, 15 minutes designing the storage architecture, 10 minutes discussing scaling and trade-offs, 10 minutes answering questions.

Explain how different storage types fit different data and access patterns

Discuss trade-offs between consistency, availability, and partition tolerance

Highlight importance of caching for performance

Show awareness of scaling challenges and mitigation strategies

Use real-world analogies like choosing the right container for different items

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