What Happens When You Hit Search? Every Stop in 190 Milliseconds

DNS, routers, TCP, TLS, the edge and the search itself, and why the same app can be four times slower

Hit search in an e-commerce app. Your request leaves your phone, crosses about a thousand kilometres and comes back with results, all in about 190 milliseconds. A blink takes about 300.

In between, it makes seven stops: DNS → Routers → Handshake → Lock → Edge → Search → Back.

And here's the twist: the exact same app, running the exact same code, can be four times slower just because its servers are in the wrong place. No engineer in the world can fix that part. By the end of this article you'll know why. If you'd rather watch, here's the 8-minute animated version:

We'll follow Ananya, in Bengaluru, as she searches for "wireless headphones" on a store at shop.example.com. The numbers are an illustrative model, not a live benchmark: a fresh connection, a full TLS 1.3 handshake and a simplified request path.

Stop 1: DNS (30 ms)

Your phone knows the name shop.example.com, but computers don't route by names. They use IP addresses, like phone numbers for machines.

So your phone asks a DNS resolver: where is this? If the answer isn't cached, the resolver asks a root server, then the .com servers, then the store's own authoritative name server, which finally returns the IP.

The clever part is that the answer can depend on where you are. Ananya is in Bengaluru, so she gets the address of a server near her, in Mumbai, not one on the other side of the world.

About 30 milliseconds, and the answer is cached for next time.

Stop 2: The routers

Your search travels as IP packets, each stamped with where it's from and where it's going. From your Wi-Fi or mobile network to your internet provider, then router after router.

Each router looks only at the destination address and forwards the packet one hop closer. No single router knows the whole journey. To Mumbai, that's about 10 hops and 1,000 km.

Stop 3: The TCP handshake (25 ms)

Before any data moves, your phone and the server shake hands. Your phone sends SYN: "Can we talk?" The server replies SYN-ACK: "Yes, I hear you." Your phone sends ACK: "Great." That's one full round trip, about 25 ms, before your search is even sent.

Why bother? Because TCP guarantees every byte arrives complete and in order. It numbers the data, waits for acknowledgements and resends anything that's lost. That's what you want for a search or a payment.

A video call or a game is different. It often uses UDP, which skips the handshake and never resends, because fresh data matters more than an old packet. Hold on to that: UDP comes back later.

Stop 4: The lock (25 ms)

Without encryption, every router on the way could read what you searched, and later your card number. So HTTPS adds TLS.

In a full TLS 1.3 handshake, your phone and the server agree on secret keys, and the server shows a certificate proving it really is the store. One more round trip, 25 ms. After that, every router only sees scrambled data. On a return visit, session resumption can skip most of this.

Notice that every stop so far has been close by. Remember that.

Stop 5: The edge and the load balancer (30 ms)

The search reaches an edge server in Mumbai, one of many edge locations around the world. The edge blocks bad traffic with a web application firewall and already holds the images and scripts, so they never travel far.

Live prices and stock can't be cached there, so the search is forwarded to the data centre. A load balancer picks one of many identical servers, using simple rules like round robin or least connections, so no single machine gets crushed.

About 30 ms. And your search still hasn't been searched.

Stop 6: The real work (80 ms)

An API gateway checks the request: is this a real user, are they sending too many requests, and which service should handle it? It goes to the search service.

"Headphones" is a popular search, so the answer may already be in a cache in memory. If not, the service asks a search index, which jumps straight to the matches instead of reading every product, just like a database index ([DATABASE INDEXES MEDIUM LINK]).

At the same time, a price service and an inventory service fetch live prices and stock. They run in parallel, and the result is assembled when they're all done. 80 ms.

Stop 7: The way back

The results go back over the connection that's already open, so there's no new handshake and no new lock. Back through the load balancer, the edge and the routers to the phone, where the images were already waiting.

Total: 190 ms. Ananya didn't even blink.

Now move the servers to Virginia

Same store, same servers, same code, but it all runs from one data centre in Virginia, in the United States. Same search, from Bengaluru. Before you read on, guess: about 200 ms, 400 ms, or close to a full second?

Close to a full second: 770 ms, four times slower with the exact same code.

The handshake, the lock and the request are each a round trip. To Mumbai a round trip is 25 ms. To Virginia and back it's 220 ms. Three of those, plus 30 ms of DNS and the same 80 ms of work, makes 770.

The stop no one can fix

The problem is distance. Light in fibre travels about 200,000 km per second. Bengaluru to Virginia is about 14,000 km, so one way takes 70 ms and a round trip at least 140 ms. That's the floor for every round trip, even on a perfect network. Real networks add routing and congestion on top.

You can buy faster servers. You can tune your database. You can rewrite your code. You can't make light faster.

How big stores win: fewer trips, shorter trips

Fewer round trips. Keep the connection open so the next search skips the handshake and the lock. HTTP/2 lets many requests share that one connection. HTTP/3 is where UDP comes back: it runs on QUIC, which builds reliability on top of UDP and sets up the connection and encryption together in a single round trip.

Shorter round trips. Put edges and data centres close to the people using them. That's why Ananya's search went to Mumbai, not Virginia.

But running in many regions isn't free. You have to keep data in sync, handle failover and pay for all of it. So the goal isn't servers everywhere. It's the right servers in the right places.

The whole trip on one screen

• DNS turns a name into a nearby address.

• Routers forward packets hop by hop.

• TCP sets up a reliable connection, and TLS locks it.

• The edge and the load balancer get you to a healthy server close by.

• The gateway, cache and search index find the answer.

• Every round trip pays for distance, so fewer trips and shorter trips win.

Watch the full animated version: Link

What was your guess for Virginia? And which stop surprised you most?