Latency and the Request Path

By the Syncfusion DevTutorials team · Last updated October 20, 2026

Follow one request from the phone to the database and back, learn the latency numbers worth remembering, and find out where the time really goes and how to cut it.

Think about posting a letter to a friend in another city.

Writing the letter takes only a minute. After that, the letter begins a much longer journey. It goes to the post office, onto a truck, through sorting centers, onto another truck, and finally arrives at your friend's door. Most of the waiting happens while the letter is travelling, not while you are writing it.

A request on the internet works in much the same way. The server might need only a few milliseconds to do its actual work, while most of the time is spent travelling across networks and waiting for other systems to respond.

The main idea: when something feels slow, first find out where the time is being spent. In many systems, travelling and waiting take longer than the actual work.

What You Will Learn

In this lesson, you will learn:

1. What latency is and how it differs from throughput.
2. The latency numbers worth remembering.
3. Why distance matters so much.
4. Every stop a request makes, from the phone to the database and back.
5. Five practical ways to reduce waiting time.
6. Why calls made at the same time beat calls made one after another.
7. Why the slowest request matters more as a system grows.

What Latency Is

Latency is how long one request takes from start to finish. It is measured in milliseconds (ms), where one millisecond is one thousandth of a second.

When a customer taps a restaurant in QuickBite, latency includes every step in the journey: travelling across the network, reaching the server, reading data, generating a response, and returning the result to the device.

For a sense of scale:

• 100 ms feels instant to a person.
• 1,000 ms (one second) feels noticeably slow.
• 3,000 ms and many users become impatient or leave.

Latency vs Throughput

Latency and throughput are often confused because both describe performance.

A highway provides an easy way to understand the difference. Imagine a road between two cities. A single car takes two hours to complete the journey, while the highway has four lanes that allow thousands of cars to travel every hour.

Now map that example to a computer system:

• Latency is how long one car takes to reach its destination.
• Throughput is how many cars can use the road during a period of time.

Adding more lanes increases throughput, but the journey still takes two hours. Making the road shorter reduces latency.

These are different problems and require different solutions.

In simple words: latency means "how long for one?" while throughput means "how many at once?"

Numbers Worth Remembering

The Latency Ladder

Different kinds of work take dramatically different amounts of time.

A round trip means a message goes somewhere and the response comes back.

These numbers come from a well-known list first published around 2012. Hardware is faster now, but the important thing is that the gaps between the rows remain enormous.

Network operations are often thousands or even millions of times slower than memory operations. That difference matters far more than the exact number itself.

Make the Numbers Human

Tiny numbers are hard to imagine.

So pretend one nanosecond lasts one whole second and compare the same operations again:

Memory is a short coffee break. A trip to another continent is a four-year degree.

This is why systems try hard to:

• keep data in memory;
• reduce network trips;
• place systems closer together.

Distance Matters

Many performance problems are actually geography problems.

Data cannot instantly appear on the other side of the world. It must travel through physical fiber-optic cables. Inside those cables, data moves at roughly 200,000 km per second, which is about two thirds of the speed of light.

That sounds incredibly fast, but over large distances even light takes time.

Distance creates a minimum possible latency that software cannot remove.

Step through a request from Bengaluru to London, about 8,000 km in a straight line:

At 200 km each millisecond, one way takes at least 40 ms and a round trip at least 80 ms. Real cables bend and routers add delay, so real trips take longer.

Imagine a QuickBite customer in Bengaluru while the servers are hosted in London.

Every request costs at least 80 milliseconds simply because of physics. If a page requires four separate round trips, that alone consumes more than the entire 300 ms budget before any application code runs.

In simple words: software cannot beat the speed of light. Bringing servers, caches, or copies of data closer to users is often the only solution.

The Journey of One Request

Every Stop on the Way

When a customer taps a restaurant, the request does not travel directly from the phone to the database.

Instead, it passes through several systems. Each system adds a small amount of delay. By itself each delay is tiny, but together they determine whether the experience feels fast or slow.

Let's follow one request.

1. DNS lookup. The phone knows the name quickbite.com, but needs a number address. It asks DNS, the internet's phone book.
2. Connect and secure. The phone and the server establish a TCP connection and negotiate TLS encryption.
3. Load balancer. The request arrives at a load balancer, which chooses one of QuickBite's servers.
4. App server. The server runs QuickBite's business logic.
5. Cache or database. The application retrieves menu data from a cache or database.
6. Response. The completed response travels back to the phone.
7. Photos. Images are often downloaded from a CDN that stores copies closer to users.

Add It Up

Here is the time for each stop on a normal day when the customer is in the same country as the servers.

Notice that the application code takes only 15 ms, roughly a tenth of the total response time.

Many teams immediately try to optimize code, but in this example the code is already fast. Most of the delay comes from network operations and data access.

That is why measuring the entire request path is more important than guessing.

Try It: Follow the Request

Flip the switches and press Play to watch the request travel.

Then try to make it as fast as you can.

Five Ways to Cut Waiting Time

Each fix removes or shortens one stop on the journey.

The biggest wins usually come from cutting round trips, not from making code faster.

One After Another, or All at Once?

The Problem

To build a menu page, QuickBite's server needs three things:

• the menu (40 ms);
• today's offers (60 ms);
• the ratings (30 ms).

A common mistake is requesting them one after another. Each request waits for the previous one to finish, so the waiting time adds up.

If the requests do not depend on each other, they can all start together.

See the Difference

The sequential approach adds all waiting times together. The parallel approach waits only for the slowest request. Step through both:

The code behind the animation:

Asking at the same time cuts 130 ms down to 60 ms

const calls = [
  { name: "menu", ms: 40 },
  { name: "offers", ms: 60 },
  { name: "ratings", ms: 30 },
];

// One after another: each call waits for the one before it.
const oneAfterAnother = calls.reduce((sum, c) => sum + c.ms, 0);

// At the same time: all start together; we wait for the slowest.
const atTheSameTime = Math.max(...calls.map((c) => c.ms));

console.log(`One after another: ${oneAfterAnother} ms`);
console.log(`At the same time:  ${atTheSameTime} ms`);
console.log(`Saved: ${oneAfterAnother - atTheSameTime} ms`);

Expected output:

One after another: 130 ms
At the same time:  60 ms
Saved: 70 ms

One after another takes 130 ms. At the same time takes 60 ms. That saves 70 ms.

This works only when the calls are independent. If one result is needed before another request can begin, they must remain in order.

Why the Slowest Request Matters More as You Grow

One Slow Call Spoils the Page

Many teams focus only on averages, but that can be misleading.

Imagine a helper service that is slow only 1% of the time. That sounds harmless at first.

Now imagine a page that depends on 100 helper services. The page finishes only after the slowest helper finishes.

The question becomes:

What is the chance that at least one of those 100 helpers is slow?

The chance that every call is fast is 0.99 multiplied by itself once per call. The chart shows the rest:

The rare slow case becomes the normal case.

This effect is called tail latency because it comes from the slow end of the latency distribution: the p99 from Lesson 1.

As systems grow larger, tail latency becomes increasingly important because users experience the slowest component rather than the average component.

In simple words: the more pieces a page needs, the more the slowest piece decides how the page feels. That is why large systems watch p99, not just the average.

Common Mistakes

Practice

What to Remember

• Latency is how long one request takes. Throughput is how many get done at once.
• Memory is fast, disks are slower, and networks are slowest.
• Distance sets a floor that no code can beat.
• A request makes many stops: DNS, connect, load balancer, server, cache or database, back, photos.
• Most time goes to travel and waiting, not to running code.
• Cut round trips: remember DNS, keep connections open, use a cache and a CDN, and stay near users.
• Make independent calls at the same time.
• With many calls per page, the slowest one decides the speed. Watch the p99.

Further Reading

These are the sources this lesson was checked against:

• Latency Numbers Every Programmer Should Know: the classic list of rough timings that the ladder above is based on.
• System Design Primer: latency vs throughput, DNS, CDNs and load balancers, with diagrams.
• Google SRE Workbook: Implementing SLOs: why percentile goals capture the slow tail that averages hide.

Next: Load Balancing, where you share QuickBite's lunch rush across several servers and watch the p99 change.