What is the difference between latency, bandwidth, and throughput?

Question

IT Interview Practice · Accepted Answer

These three describe different things and are constantly confused. **Latency** is *delay* — how long one unit of data takes to travel from A to B (measured in time, e.g. ms). **Bandwidth** is *capacity* — the maximum data rate a link can carry (e.g. Gbps). **Throughput** is the *actual* rate you achieve in practice, which is usually below bandwidth. A pipe analogy makes it click:

```text
   ├────────────── length of pipe = LATENCY (how long to traverse) ─────────────┤
   ╔══════════════════════════════════════════════════════════════════════════╗
   ║  width of pipe = BANDWIDTH (max capacity)                                  ║
   ║  water actually flowing = THROUGHPUT (real achieved rate ≤ bandwidth)      ║
   ╚══════════════════════════════════════════════════════════════════════════╝
```

Crucially, **a wider pipe does not make it shorter**: adding bandwidth doesn't reduce latency. A fat transatlantic link still has ~80 ms of round-trip latency dictated by distance and the speed of light — you can't buy your way under it. This is why latency, not bandwidth, dominates the feel of interactive apps: each round trip (DNS, TCP handshake, TLS, then the request) pays the latency toll, and they add up.

Latency and throughput interact through the **Bandwidth-Delay Product** (BDP = bandwidth × round-trip time), the amount of data "in flight" to keep a pipe full. On a high-bandwidth, high-latency "long fat network," a protocol like TCP that waits for ACKs can't fill the pipe unless its window is at least the BDP — so throughput ends up *limited by latency*, not bandwidth. That's why one TCP stream over a long distance often underperforms even on a fast link, and why parallelism, larger windows, and CDNs (which cut distance, hence latency) help.

## Why it matters

Conflating these three is one of the most common — and most consequential — performance mistakes: teams buy more bandwidth to fix what is really a latency problem and see no improvement. The senior insight is that **latency is a floor set by physics** (distance) that you attack architecturally — put servers/CDNs closer to users, reduce round trips (connection reuse, HTTP/3, caching), and batch requests — while bandwidth is something you can often just provision. Understanding BDP explains counter-intuitive results like a "fast" link delivering slow single-stream transfers, which is exactly the kind of reasoning expected when you design or debug high-performance, geographically distributed systems.

Why it matters

Related questions