Why database scaling handles data growth in HLD - Design It to Understand It

Design: Database Scaling for Data Growth

Focus on database scaling techniques to handle data growth. Out of scope are application-level caching strategies and network infrastructure scaling.

Functional Requirements

FR1: Support increasing volume of data without performance degradation

FR2: Maintain fast query response times as data size grows

FR3: Ensure data availability and durability

FR4: Handle concurrent read and write operations efficiently

Non-Functional Requirements

NFR1: Scale to handle up to 10TB of data initially, with growth expected to 100TB within 2 years

NFR2: Maintain p99 query latency under 200ms

NFR3: Ensure 99.9% uptime for database services

NFR4: Support at least 1000 concurrent users performing reads and writes

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Database server(s)

Load balancers

Caching layers

Data partitioning or sharding mechanisms

Replication for availability

Backup and recovery systems

Design Patterns

Vertical scaling (scaling up)

Horizontal scaling (scaling out)

Sharding (data partitioning)

Replication (master-slave, multi-master)

Caching (read-through, write-through)

Eventual consistency vs strong consistency

Reference Architecture

Client
  |
  v
Cache Layer (e.g., Redis)
  |
  v
Load Balancer
  |
  v
+-------------------+       +-------------------+
|   Database Node 1  |<----->|   Database Node 2  |
+-------------------+       +-------------------+
          |                          |
          v                          v
      Storage                    Storage

Backup System connected to all Database Nodes

Components

Load Balancer

Nginx or HAProxy

Distributes client requests evenly across database nodes

Database Nodes

PostgreSQL or MySQL Cluster

Store and manage data; handle queries and transactions

Cache Layer

Redis or Memcached

Serve frequent read queries quickly to reduce database load

Replication Mechanism

Database native replication

Keep copies of data synchronized for availability and failover

Backup System

Automated backup tools

Ensure data durability and recovery in case of failure

Request Flow

1. Client sends query request to Cache Layer

2. Cache Layer serves read queries if data is cached; otherwise forwards to Load Balancer

3. Load Balancer routes request to appropriate Database Node based on sharding or load

4. Database Node queries storage for cache misses or processes write queries

5. For write queries, Database Node updates storage and replicates changes to other nodes

6. Cache Layer is updated or invalidated after writes to maintain consistency

7. Backup System periodically saves data snapshots for recovery

Database Schema

Entities: Data Records with unique keys Relationships: Data partitioned by key ranges or hash (sharding) Replication: Each shard replicated to at least one standby node Indexes: Used on frequently queried fields to speed up reads

Scaling Discussion

Bottlenecks

Single database node CPU or memory limits (vertical scaling limit)

Disk I/O bottlenecks on large data volumes

Network bandwidth limits between nodes and clients

Replication lag causing stale reads

Cache invalidation complexity with frequent writes

Solutions

Move from vertical scaling to horizontal scaling by adding more database nodes

Implement sharding to split data across multiple nodes to distribute load

Use faster storage solutions like SSDs or NVMe drives

Optimize replication with asynchronous or semi-synchronous modes balancing consistency and latency

Use intelligent cache invalidation strategies or write-through caches to keep cache fresh

Interview Tips

Time: Spend 10 minutes understanding requirements and constraints, 20 minutes designing the architecture and data flow, 10 minutes discussing scaling challenges and solutions, 5 minutes summarizing key points.

Clarify data growth expectations and query patterns before designing

Explain difference between vertical and horizontal scaling

Describe sharding and replication clearly with pros and cons

Discuss caching benefits and challenges

Highlight trade-offs between consistency and availability

Mention backup and recovery importance for data durability

Practice

1. Why do systems use database scaling when data grows larger?

easy

A. To keep data access fast and reliable

B. To reduce the amount of data stored

C. To make data harder to access

D. To delete old data automatically

Solution

1. Step 1: Understand the purpose of scaling

   Database scaling is used to handle more data without slowing down or losing reliability.

2. Step 2: Identify the correct goal

   The main goal is to keep data access fast and reliable as data grows.

3. Final Answer:

   To keep data access fast and reliable -> Option A

4. Quick Check:

   Scaling improves speed and reliability [OK]

Hint: Scaling keeps databases fast despite growth [OK]

Common Mistakes:

• Thinking scaling reduces data size
• Believing scaling deletes old data
• Assuming scaling makes data harder to access

2. Which of the following is a correct example of vertical scaling in databases?

easy

A. Adding more servers to share the load

B. Upgrading a server with a faster CPU and more RAM

C. Splitting data into smaller parts across servers

D. Copying data to multiple servers for backup

Solution

1. Step 1: Define vertical scaling

   Vertical scaling means improving one server's hardware like CPU or RAM.

2. Step 2: Match the option to vertical scaling

   Upgrading a server with better CPU and RAM fits vertical scaling.

3. Final Answer:

   Upgrading a server with a faster CPU and more RAM -> Option B

4. Quick Check:

   Vertical scaling = better single server [OK]

Hint: Vertical scaling upgrades one server's hardware [OK]

Common Mistakes:

• Confusing vertical with horizontal scaling
• Thinking adding servers is vertical scaling
• Mixing sharding with vertical scaling

3. Given a database system that uses sharding, what happens when data grows beyond one shard's capacity?

medium

A. The system slows down because all data is on one server

B. Replication copies data to the same shard

C. Data is deleted to keep the shard size small

D. New shards are added to distribute the data load

Solution

1. Step 1: Understand sharding

   Sharding splits data across multiple servers or shards to spread load.

2. Step 2: What happens when one shard is full?

   New shards are added to hold more data and keep performance.

3. Final Answer:

   New shards are added to distribute the data load -> Option D

4. Quick Check:

   Sharding adds shards as data grows [OK]

Hint: Sharding adds servers to handle more data [OK]

Common Mistakes:

• Thinking data is deleted when shard is full
• Believing replication happens on same shard
• Assuming system slows down without adding shards

4. A database uses replication to improve read speed and backup. If replication is misconfigured, what problem might occur?

medium

A. Data inconsistency between primary and replicas

B. Faster writes on the primary database

C. Automatic deletion of all replicas

D. Sharding data across replicas

Solution

1. Step 1: Understand replication purpose

   Replication copies data to replicas for speed and backup.

2. Step 2: Identify misconfiguration effects

   If replication is wrong, replicas may not match primary, causing inconsistency.

3. Final Answer:

   Data inconsistency between primary and replicas -> Option A

4. Quick Check:

   Replication errors cause inconsistency [OK]

Hint: Misconfigured replication causes data mismatch [OK]

Common Mistakes:

• Thinking replication speeds up writes
• Assuming replicas get deleted automatically
• Confusing sharding with replication

5. A company expects its user data to grow rapidly. Which combination of scaling techniques best handles this growth while ensuring fast reads and fault tolerance?

hard

A. Vertical scaling only, upgrading server hardware

B. Replication only, copying data to multiple servers

C. Horizontal scaling with sharding and replication

D. Deleting old data regularly to reduce size

Solution

1. Step 1: Analyze growth and requirements

   Rapid data growth needs spreading data and fast access with backups.

2. Step 2: Match techniques to needs

   Horizontal scaling adds servers; sharding splits data; replication copies data for speed and fault tolerance.

3. Step 3: Evaluate other options

   Vertical scaling alone can't handle rapid growth well; replication alone doesn't split data; deleting data loses information.

4. Final Answer:

   Horizontal scaling with sharding and replication -> Option C

5. Quick Check:

   Sharding + replication = scalable and reliable [OK]

Hint: Combine sharding and replication for growth and speed [OK]

Common Mistakes:

• Relying only on vertical scaling for big growth
• Using replication without sharding for large data
• Deleting data instead of scaling