| Scale | Throughput (requests/sec) | Latency (ms) | Availability (%) | What Changes? |
|---|---|---|---|---|
| 100 users | ~50 | ~50 | 99.9 | Single server handles requests easily; low latency; simple setup |
| 10,000 users | ~5,000 | ~100 | 99.95 | Need load balancer; some caching; latency slightly increases |
| 1,000,000 users | ~500,000 | ~200 | 99.99 | Multiple servers; database replicas; CDN; latency affected by network |
| 100,000,000 users | ~50,000,000 | ~300+ | 99.999 | Global distribution; sharding; advanced caching; complex failover |
Throughput, latency, and availability in HLD - Scalability & System Analysis
At small scale, the application server CPU and memory can handle throughput and latency well.
As users grow to thousands, the database becomes the first bottleneck because it handles many read/write operations.
At millions of users, network bandwidth and latency limit performance, affecting availability.
- Horizontal scaling: Add more servers behind load balancers to increase throughput and reduce latency.
- Caching: Use in-memory caches (like Redis) to reduce database load and improve latency.
- Database replication: Use read replicas to spread read traffic and improve availability.
- Sharding: Split database by user or data to handle large scale writes and reads.
- Content Delivery Network (CDN): Cache static content closer to users to reduce latency globally.
- Failover and redundancy: Use multiple data centers and automatic failover to improve availability.
- At 1,000 users: ~50 requests/sec, easily handled by 1 server with 1 Gbps network.
- At 1 million users: ~500,000 requests/sec, need ~100 servers (assuming 5,000 req/sec/server).
- Database: Single instance handles ~10,000 QPS; need replicas and sharding beyond that.
- Bandwidth: 1 Gbps = 125 MB/s; high throughput requires multiple network interfaces or data centers.
- Latency: Network and disk I/O dominate; caching reduces disk reads and improves response times.
Start by defining throughput, latency, and availability in simple terms.
Explain how each metric affects user experience and system design.
Discuss bottlenecks at different scales and propose targeted solutions.
Use real numbers to show understanding of system limits and scaling techniques.
Your database handles 1,000 QPS. Traffic grows 10x to 10,000 QPS. What do you do first?
Answer: Add read replicas to distribute read load and implement caching to reduce database hits. Consider sharding if writes also increase significantly.
Practice
Solution
Step 1: Understand throughput meaning
Throughput measures the amount of work or requests a system can process in a given time.Step 2: Compare with other metrics
Latency measures response time, availability measures uptime, scalability is about growth capacity.Final Answer:
Throughput -> Option AQuick Check:
Throughput = Requests per second [OK]
- Confusing latency with throughput
- Mixing availability with throughput
- Thinking scalability equals throughput
Solution
Step 1: Define latency
Latency is the delay or time taken for a system to respond to one request.Step 2: Eliminate other options
The total number of requests processed per second describes throughput. The ability to add more servers to handle load describes scalability. The percentage of time the system is operational describes availability.Final Answer:
The time taken to respond to a single request -> Option BQuick Check:
Latency = Response time [OK]
- Confusing latency with throughput
- Thinking availability is latency
- Mixing scalability with latency
Solution
Step 1: Calculate throughput
Throughput = total requests / total time = 1000 / 10 = 100 requests per second.Step 2: Understand latency
Latency is given as 5 milliseconds per request.Final Answer:
Throughput: 100 requests/sec, Latency: 5 ms -> Option DQuick Check:
Throughput = 100, Latency = 5 ms [OK]
- Dividing latency by number of requests
- Confusing throughput units
- Multiplying latency by total requests
Solution
Step 1: Calculate total minutes in a day
24 hours x 60 minutes = 1440 minutes per day.Step 2: Calculate availability
Availability = (Total time - downtime) / Total time = (1440 - 10) / 1440 = 1430 / 1440 ≈ 0.9931 or 99.31%.Step 3: Compare with claim
Claim is 99.9%, actual is 99.31%, so claim is incorrect.Final Answer:
Actual availability is 99.31%, claim is incorrect -> Option AQuick Check:
Availability = 99.31%, Claim wrong [OK]
- Using hours instead of minutes
- Incorrectly subtracting downtime
- Misreading percentage claim
Solution
Step 1: Analyze throughput and availability needs
10,000 requests/sec and 99.99% availability require scaling and fault tolerance.Step 2: Evaluate design options
Using a single powerful server with caching or optimizing CPU speed on one server risks overload and downtime. Using a database with strong consistency but no replication risks availability due to lack of fault tolerance. Distributing load across multiple servers with load balancers and health checks supports scaling and high availability.Final Answer:
Distribute load across multiple servers with load balancers and health checks -> Option CQuick Check:
Scaling + availability = load balancer + health checks [OK]
- Relying on single server for high throughput
- Ignoring replication for availability
- Focusing only on latency without scaling
Ready to prove it?
Pass the test and this pattern moves unknown
