In this chapter
We'll meet throughput — how much data can move per second, a different question from latency — and use a real worked example (GreenMart's own nightly export slowing from 20 minutes to nearly 3 hours) to see exactly how a throughput ceiling shows up in practice.
The Problem in Real Life
Sarah checks the overnight job logs. The nightly export — a full backup of GreenMart's catalog and order history — used to finish in twenty minutes. Lately it's taking almost two hours.
"This isn't a latency problem," Sarah says. "One slow request wouldn't do this. This is about how much data can move at once."
This job isn't waiting on one slow answer. It's moving a genuinely huge amount of data, and that's a different problem.
Sarah
One Fast Answer vs. Moving a Lot of Data
Throughput and latency answer different questions
Latency is how fast one request starts; throughput is how much data can move once it's flowing — a storage system can be strong at one and weak at the other.
The slowest link in the chain sets the real ceiling
A fast drive behind a slower connection is still limited by the connection — knowing which one is the actual bottleneck matters before spending money.
Throughput
Throughput is how much data can move in a given amount of time — measured in something like megabytes or gigabytes per second — and it answers a genuinely different question than latency does. Latency asks how long one request takes to start getting an answer; throughput asks how much total data can flow once it's moving.
- Why they're not the same thing. A storage device can have excellent latency (fast to start responding) but limited throughput (slow to move a large volume once it does), or the reverse — good at sustained bulk transfer, but slower to respond to the very first request. GreenMart's nightly export is a real, pure throughput problem: it's not waiting on one slow answer, it's moving GreenMart's entire catalog and order history, and every added gigabyte adds real time.
- What actually limits throughput. The storage device itself has a real maximum transfer rate. The connection between the storage and the machine reading it (a real, physical or network link) has its own real maximum. Whichever of these is slowest sets the actual ceiling — adding a faster drive doesn't help if the connection to it was already the bottleneck, and GreenMart has to know which one is actually limiting before spending money to fix it.
- Why bulk jobs care about throughput specifically, not latency. A single database query — one row, fetched once — barely notices throughput at all; its whole cost is latency. A nightly export moving gigabytes, a full data migration, or a large file upload cares almost entirely about throughput, and barely at all about the latency of any one individual read. Knowing which kind of job GreenMart is actually running is what tells you which number is worth optimizing.
| Point in Time | Data Being Exported | Storage Link's Real Throughput | Real Export Time |
|---|---|---|---|
| A year ago | ~5 GB (catalog + a few months of orders) | ~250 MB/s | ~20 minutes |
| Today | ~40 GB (two years of images, orders, logs) | ~250 MB/s (unchanged) | ~2.7 hours |
The storage link's own throughput never actually changed — the data volume grew roughly 8x while the ceiling stayed fixed, and the export time grew right along with it. This is a real capacity-growth problem (previous chapter) showing up as a real throughput problem.
The nightly export didn't get slower because anything broke. It got slower because GreenMart's own real data growth (the previous chapter's own subject) finally caught up to a throughput ceiling that was always there, just never tested until now.
Key Takeaway
Throughput and latency are answers to two genuinely different questions — how fast one request starts, versus how much data can move once it's flowing — and a real performance problem is only diagnosable once you know which one you're actually looking at.
Why This Matters
Treating every slow operation as a latency problem — trying to make one request start faster — does nothing for a genuine throughput problem like GreenMart's nightly export, where the real fix is a faster link or moving less data, not a faster individual answer.
GreenMart now has real vocabulary for the export slowdown: not a latency problem, a throughput ceiling finally being tested by real data growth. The next chapter completes this trio with a third, genuinely different question: not how much data moves, but how many separate operations a storage system can handle each second.