Grokking the System Design Interview

0% completed

Latency vs Throughput

On This Page

Two Different Numbers

They Are Separate Numbers

Concurrency Connects Them

Why They Trade Off Near Capacity

Batching Trades Latency for Throughput

Measure Latency With Percentiles

Slow Requests Add Up

How to Improve Latency

How to Improve Throughput

A Cache Improves Latency First

Latency and Throughput Side by Side

Choosing What to Optimize

Using These Numbers in an Interview

Key Takeaways

Practice Questions

A food delivery app works well at 4 PM. Each menu page opens in about 150 ms. At 8 PM, ten times more people open the app to order dinner. The same page now takes 3 seconds to open.

The servers did not become slower. Each request still needs the same amount of work. What changed is how many requests arrived at the same time.

This shows that "fast" can mean two different things. It can mean that one request finishes quickly. It can also mean the system finishes many requests every second. These are two different numbers, called latency and throughput. This lesson explains both numbers, how they are connected, and when improving one costs the other.

Two Different Numbers

Latency is the time one request takes, from the moment it is sent to the moment the response arrives. It is measured in milliseconds (ms). Lower latency is better.

The latency of one request usually has three parts:

Network time. The request and response travel between the user and the server.
Waiting time. The request waits in a queue until a server is free to work on it.
Processing time. The server does the actual work, like reading from a database and building the response.

Throughput is the amount of work a system completes in a unit of time. For web systems, it is usually counted as requests per second (RPS), also called queries per second (QPS). Higher throughput is better.

A supermarket checkout shows the difference. Latency is how long one customer spends at the checkout. Throughput is how many customers the store serves in one hour.

In short: latency is about one request, and throughput is about all the requests together.

Latency follows one request from send to response, while throughput counts all the requests finished in one second

They Are Separate Numbers

Latency and throughput are not opposites. A system can be good at one and bad at the other. All four combinations exist.

	Low throughput	High throughput
Low latency	One fast server, handling one request at a time	The goal, and it usually costs more money
High latency	An overloaded system, which is the failure case	A batch job that processes a billion records over six hours

The batch job is a useful example. Nobody waits for a single record, so latency does not matter much. But the job processes a huge number of records, so its throughput is very high.

Concurrency Connects Them

Concurrency is the number of requests being worked on at the same time.

Suppose one worker takes 100 ms to finish a request. It can finish 10 requests per second. Now add nine more workers, for ten in total. Together they finish 100 requests per second. But each request still takes 100 ms.

Throughput became ten times higher. Latency did not change. The extra throughput came from more concurrency.

This relationship is called Little's Law:

concurrency = throughput x latency

Little's Law turns capacity questions into simple arithmetic. Suppose a service must handle 2,000 requests per second, and each request takes 50 ms (0.05 seconds). Then 2,000 x 0.05 = 100 requests are being processed at any moment. This number tells you how many threads, connections, or servers you need.

Ten workers finish ten times more requests per second while each request still takes 100 ms, which is Little's Law: concurrency = throughput x latency

Why They Trade Off Near Capacity

If the two numbers are separate, why do people call them a trade-off? The answer is capacity.

Utilization is the share of a server's capacity that is in use. At 50 percent utilization, the server is busy half of the time.

When a server is busy, a new request cannot start right away. It waits in a queue. That waiting time is added to its latency. The busier the server, the longer the queue, and the longer each request waits.

Here is a simple queueing model. Each request needs 10 ms of work. The table shows the average latency at different utilization levels.

Utilization	Average latency
50 percent	20 ms
70 percent	33 ms
80 percent	50 ms
90 percent	100 ms
95 percent	200 ms

The work per request stays the same. Only the waiting time grows. In this model, latency equals the work time divided by the free share of capacity. At 90 percent utilization, only 10 percent is free, so 10 ms becomes 100 ms.

In a simple queueing model, average latency grows from 20 ms at 50 percent utilization to 200 ms at 95 percent, because requests wait in a queue

The pattern has three zones:

Below about 70 percent, latency grows slowly.
Between 70 and 90 percent, latency climbs quickly, and each extra unit of load adds less throughput.
Above about 90 percent, throughput stops growing, and latency rises very steeply.

This is why teams usually run servers at 50 to 70 percent utilization, not at 95 percent. The spare capacity is not wasted. It keeps latency stable when traffic suddenly rises, like the dinner rush in the delivery app.

Batching Trades Latency for Throughput

Sometimes a team accepts higher latency on purpose, to get more throughput. The clearest example is batching. Batching means collecting many items and processing them together in one operation.

Suppose writing one record to a database takes 5 ms. Writing records one by one gives at most 200 records per second.

Now the service collects 100 records and writes them in one call, which takes 50 ms. That gives up to 2,000 records per second. Throughput became ten times higher.

But the first record in each batch must wait for the other 99 records to arrive. Its latency becomes much higher. So batching improves throughput, but it increases the latency of each item.

Writing 100 records in one call raises throughput from 200 to 2,000 records per second, but each record waits for the batch to fill

Buffering and queueing work in the same way. They raise throughput by making single items wait longer.

Measure Latency With Percentiles

An average latency can hide serious problems. Here is an example with 100 requests:

98 requests take 100 ms.
2 requests take 5,000 ms, because of retries or a slow database lock.

The average is (98 x 100 + 2 x 5,000) / 100 = 198 ms. That looks healthy. But two out of every hundred users wait five seconds, and those are the users who complain.

So real systems measure percentiles. To find them, sort all the request times from fastest to slowest.

p50, also called the median: half of the requests take this long or less. It shows the typical experience.
p95: 95 percent of the requests take this long or less. At most one request in 20 is slower.
p99: 99 percent of the requests take this long or less. At most one request in 100 is slower. It shows the experience of the slowest users.

In the example, p50 is 100 ms and p95 is 100 ms. But p99 is 5,000 ms, and it shows the problem that the average hid.

For 100 requests where 2 take 5,000 ms, the average of 198 ms looks healthy, while the p99 of 5,000 ms shows the slow requests

Latency targets are usually written in a service level objective (SLO). An SLO is a promised performance target, like "p99 latency under 200 ms". "The API should be fast" is not a target, because nobody can measure it.

Slow Requests Add Up

The slow one percent matters more than it seems. One page load often makes many backend calls, not just one.

Suppose a page makes 100 backend calls, and each call has a 99 percent chance of being fast. The chance that all 100 calls are fast is 0.99 multiplied by itself 100 times, which is about 0.37. So about 63 percent of page loads include at least one slow call.

When one user action makes many calls, the slow requests affect most page loads. The Key Characteristics of Distributed Systems lesson covers these measurements together with availability and reliability.

How to Improve Latency

Move the data closer to users. A CDN (content delivery network) is a network of servers placed near users. It shortens the distance that each request travels.
Cache results. A cache is fast storage that keeps answers ready to use. A cache hit skips the slow work completely.
Make fewer network round trips. Each network call in a sequence adds its own latency. Run independent calls in parallel, or combine related calls into one.
Add indexes and tune queries. A slow query often reads far more data than it needs.
Do less work while the user waits. Move work the user does not need right away, like sending an email, to a background job.
Keep utilization moderate. Spare capacity keeps queues short, and it is often the cheapest fix.

How to Improve Throughput

Add more servers. Put several servers behind a load balancer, so they share the requests.
Increase concurrency. Use more workers, threads, or connections. Little's Law tells you how many you need.
Batch the work. Group items to reduce the cost per item, and accept the extra waiting.
Use a queue. Workers take jobs from a queue at their own speed, and the queue holds extra jobs during traffic spikes.
Split the data. Sharding spreads data across several databases, so one database does not limit the whole system.
Cache results. A cache also appears in this list, for the reason explained in the next section.

A Cache Improves Latency First

A cache appears in both lists, so which number does it improve?

A cache improves latency first. The answer is already computed and stored nearby, so the request skips the slow work. This is also why a CDN is mainly a latency tool.

Throughput improves as a result. On a cache hit, the backend does no work, so its capacity is free for other requests. For example, a video is processed once and then served from a cache to a thousand viewers. The backend does that work once, not a thousand times.

Most good techniques help both numbers. The techniques that truly trade one for the other add waiting on purpose, like batching, buffering, and queueing.

Latency and Throughput Side by Side

	Latency	Throughput
Measures	The time for one request	The requests completed per second
Unit	Milliseconds	RPS or QPS
Better when	Lower	Higher
Report it as	A percentile, like p99	Peak load, not only the average
Improved by	Closer data, caching, fewer round trips	More servers, concurrency, batching
Gets worse when	Utilization comes close to capacity	One slow step limits all the work

Choosing What to Optimize

A user is waiting for the response: optimize latency, and set the target as a percentile.
Nobody waits for the result, like a nightly report: optimize throughput. Higher latency is acceptable here.
The system is overloaded: add capacity or reject extra load first. Near full capacity, both numbers are bad.
You are given a scale requirement: turn it into both numbers before you design anything.

Using These Numbers in an Interview

Start by turning the scale requirement into numbers. For example, "one million daily users, each loading the feed five times a day" means 5,000,000 requests per day. One day has 86,400 seconds, so the average is about 58 requests per second. The peak is usually several times higher.

Then use Little's Law to estimate how many requests the servers must process at the same time. State every latency target as a percentile, like "p99 under 200 ms".

Two follow-up questions are common:

"How would you reduce latency?" Start with a cache or a CDN. Then add that the cache also takes load off the database, so throughput improves too.
"Why not run the servers at 95 percent utilization?" Because queues grow very quickly near full capacity. A small rise in traffic would push latency far past the target.

Key Takeaways

Latency is the time one request takes. Throughput is the number of requests completed per second.
The two numbers are separate. Little's Law connects them: concurrency = throughput x latency.
They trade off near full capacity, because requests wait in queues. Teams usually run servers at 50 to 70 percent utilization.
Batching improves throughput, but it increases the latency of each item.
Measure latency with percentiles like p50, p95, and p99. An average hides the slow requests that users notice.
A cache improves latency first. Throughput improves too, because the backend skips the work.

Latency tells you how long one user waits, and throughput tells you how many users the system can serve. A good design states a target for both. The next lesson, Horizontal vs Vertical Scaling, explains the two basic ways to add capacity.

Practice Questions

Try each question first, then open the answer.

1. A service must handle 3,000 requests per second, and each request takes 40 ms. How many requests are being processed at the same time? If one server can process 20 requests at a time, how many servers are needed?