The rungs, top to bottom
Start at the top of the ladder and walk down. A hit in the processor's own fastest cache costs about a nanosecond. Main memory is around 100 nanoseconds, so memory is already a hundred times slower than the cache sitting beside the core.
Further down. A random read from a solid state disk is roughly 100 microseconds, another factor of a thousand down. A seek on a spinning disk is about 10 milliseconds, a hundred times worse again. Each rung is not a little slower than the last. It is a different world.
The network has its own rungs. Pushing a kilobyte through a fast link takes about 10 microseconds, and a round trip inside one data centre runs about 500 microseconds. Cross the Atlantic and you pay around 100 milliseconds. Go from the United States to Asia and it is closer to 200.
Physics sets these floors, not engineering. Light in glass covers about 200 kilometres per millisecond, so New York to Amsterdam can never beat roughly 60 milliseconds for the round trip, whoever you buy your servers from.
Three bands worth memorising
Three bands is all you need, and the whole table becomes memorable. Nanoseconds mean processor and memory. Microseconds mean disks and the local network. Milliseconds mean spinning disks and anything leaving the building.
Those three bands answer most design questions on their own. Data you touch on every request wants to live in the nanosecond or low microsecond band. Anything in the millisecond band gets hidden behind a cache, a copy nearby, or work you do later.
One habit is worth stealing. When somebody quotes you a latency, ask which band it sits in before arguing about the digits. A debate over 80 against 120 milliseconds is fine. A design that confuses microseconds with milliseconds is wrong by a factor of a thousand, and those are the ones that ship.
Worked example
Tomas, a backend engineer at a food delivery startup, gets a ticket: the restaurant menu endpoint takes 900 ms. He walks the ladder. The endpoint makes 8 sequential database calls, each a same-datacenter round trip of about 500 microseconds plus a few milliseconds of query time, call it 5 ms each, so 40 ms total. That doesn't explain 900. Then he finds it: the service calls a pricing API hosted in eu-west-1 while the app runs in us-east-1, about 100 ms per round trip, and it does so 8 times in a loop. That's 800 ms of pure geography. He batches the 8 calls into one, and the endpoint drops to about 140 ms. No code got faster. One number on the ladder, cross-region at 100 ms, explained the whole ticket.