| Scale | Users | Data Volume | Traffic | System Behavior |
|---|---|---|---|---|
| Small | 100 users | Low (MBs) | Low (few QPS) | Single server handles all; simple design |
| Medium | 10,000 users | Moderate (GBs) | Moderate (hundreds QPS) | Server CPU/memory stressed; DB load increases |
| Large | 1,000,000 users | High (TBs) | High (thousands QPS) | Single server insufficient; DB bottleneck; latency rises |
| Very Large | 100,000,000 users | Very High (PBs) | Very High (hundreds of thousands QPS) | Need distributed systems; partitioning; multi-region |
Why distributed patterns solve common challenges in HLD - Scalability Evidence
Start learning this pattern below
Jump into concepts and practice - no test required
At small scale, a single server and database can handle all requests. As users grow, the database becomes the first bottleneck because it can only process a limited number of queries per second (usually up to 5,000-10,000 QPS for a single instance). CPU and memory on the application server also get stressed as traffic increases. Network bandwidth and storage limits appear at very large scale.
Distributed patterns solve these by spreading load across many machines, avoiding single points of failure and scaling horizontally.
- Horizontal Scaling: Add more servers to share load, improving capacity and fault tolerance.
- Load Balancing: Distribute incoming requests evenly to prevent overload on any one server.
- Database Replication: Use read replicas to handle read-heavy traffic, reducing load on primary DB.
- Sharding: Split data across multiple databases by key ranges or hashes to handle large data volumes.
- Caching: Store frequent data in fast memory (e.g., Redis) to reduce database hits.
- Message Queues: Decouple components and smooth traffic spikes by asynchronous processing.
- CDNs: Cache static content closer to users to reduce bandwidth and latency.
- Multi-region Deployment: Place servers near users to reduce latency and improve availability.
Example for 1 million users with 1 request per second each:
- Requests per second: 1,000,000 QPS (too high for single DB)
- Database capacity: Single DB ~10,000 QPS -> Need ~100 DB shards or replicas
- Network bandwidth: 1 Gbps = 125 MB/s; 1M QPS with 1 KB payload = ~1 GB/s -> Need multiple network links
- Storage: TBs of data requiring distributed storage solutions
- Servers: Hundreds of app servers behind load balancers
Start by describing current system limits at small scale. Identify the first bottleneck as traffic grows. Explain why that component breaks (e.g., DB QPS limit). Then propose distributed solutions step-by-step, explaining how each solves a specific problem. Use real numbers to justify your choices. Finally, mention trade-offs and monitoring needs.
Question: Your database handles 1000 QPS. Traffic grows 10x to 10,000 QPS. What do you do first and why?
Answer: The first step is to add read replicas to offload read queries from the primary database. This reduces load and increases read capacity. If writes also increase, consider sharding data or scaling the database vertically or horizontally.
Practice
Solution
Step 1: Understand the purpose of distributed patterns
Distributed patterns divide tasks among multiple machines to improve performance and fault tolerance.Step 2: Compare options with this understanding
Only They split work across machines to improve speed and reliability. correctly states the benefit of splitting work to improve speed and reliability.Final Answer:
They split work across machines to improve speed and reliability. -> Option AQuick Check:
Distributed patterns improve speed and reliability = A [OK]
- Thinking distributed means fewer users can be handled
- Assuming distributed patterns add complexity without benefits
- Believing data is centralized in distributed systems
Solution
Step 1: Identify patterns that distribute user requests
Load balancing distributes incoming requests across multiple servers to avoid overload.Step 2: Eliminate incorrect options
Single-threading and monolithic deployment do not distribute load; local caching helps speed but not load distribution.Final Answer:
Load balancing -> Option AQuick Check:
Load balancing distributes requests = B [OK]
- Confusing single-threading with load distribution
- Thinking monolithic means distributed
- Assuming caching balances load
Solution
Step 1: Understand sharding in distributed systems
Sharding splits data into smaller parts stored on different servers to allow parallel access.Step 2: Analyze options based on sharding benefits
Sharding does not reduce total data or centralize it; it improves speed by parallel queries.Final Answer:
It improves query speed by parallelizing data access. -> Option DQuick Check:
Sharding speeds queries by splitting data = D [OK]
- Thinking sharding reduces total data stored
- Believing sharding centralizes data
- Confusing sharding with replication
Solution
Step 1: Understand replication and failover
Replication copies data to multiple servers to provide backup if one fails, but failover must be configured to switch users automatically.Step 2: Identify why downtime occurs despite replication
If users face downtime, failover is likely missing or misconfigured, so traffic doesn't switch to healthy servers.Final Answer:
Replication is not configured for failover. -> Option CQuick Check:
Failover missing causes downtime despite replication = C [OK]
- Assuming replication alone prevents downtime
- Thinking too many copies cause downtime
- Believing replication centralizes data
Solution
Step 1: Identify challenges in a global platform
Speed requires spreading requests (load balancing), reliability needs data copies (replication), and scaling needs data partitioning (sharding).Step 2: Match patterns to challenges
Load balancing for requests, replication for reliability, sharding for data scaling. combines all three patterns to address speed, reliability, and scaling effectively.Step 3: Eliminate incomplete options
Options B, C, and D miss one or more key patterns, risking bottlenecks or failures.Final Answer:
Load balancing for requests, replication for reliability, sharding for data scaling. -> Option BQuick Check:
Combine load balancing, replication, sharding = A [OK]
- Relying on single server for millions of users
- Using only one pattern and ignoring others
- Confusing replication with sharding roles
