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

When you tap "Search" within an e-commerce application, your phone embarks on a journey that traverses approximately a thousand kilometres and returns with results in around 190 milliseconds. This process involves seven distinct stages: DNS resolution, network routing, TCP handshakes, TLS encryption, edge servers, the search itself, and the return journey.

Interestingly, the exact same app running the same code can be four times slower solely due to the location of its servers. This phenomenon is not amenable to engineering fixes. The remainder of this article elucidates the reasons behind this discrepancy.

Let's follow Ananya, a resident of Bengaluru, as she conducts a search for wireless headphones on the website shop.example.com. For the sake of this illustrative example, the figures represent a hypothetical benchmark and do not reflect live measurements. The model encompasses a fresh connection, a complete TLS 1.3 handshake, and a streamlined request path.

The first stop is DNS resolution, which takes approximately 30 milliseconds. Your phone recognizes the domain shop.example.com, but computers communicate using IP addresses. Consequently, your phone queries a DNS resolver to ascertain the relevant IP address. If the answer is not cached, the resolver sequentially consults root servers, .com servers, and the store's authoritative name server before transmitting the IP address.

The clever aspect is that this response can vary based on Ananya's geographical location. Since she is situated in Bengaluru, she receives the address of a server situated in Mumbai, rather than one located on the opposite side of the globe. This entire process is accomplished within a brief span of 30 milliseconds, and the response is subsequently cached for future queries.

Subsequent to DNS resolution, the IP packets traverse the network, each bearing the sender's and receiver's addresses. These packets journey from your Wi-Fi or mobile network, through your Internet Service Provider, and onward, traversing router after router until they reach Mumbai. This route encompasses roughly ten hops and a distance of 1,000 kilometers.

The TCP handshake, taking an additional 25 milliseconds, precedes the transmission of data. This initial handshake involves your phone transmitting a SYN packet, requesting a conversation, and the server responding with a SYN-ACK packet, confirming its ability to hear. Your phone subsequently acknowledges receipt with an ACK packet.

This full round trip takes approximately 25 milliseconds, occurring prior to the actual execution of the search. The rationale behind this handshake lies in TCP's assurance that every byte arrives intact and in the correct sequence. It assigns numbers to the data, awaits acknowledgments, and resends any lost packets. This process is crucial for searches and transactions but differs for videos or games, which often employ UDP for faster transmission, trading off the handshake and resend mechanisms.

Next, the lock stage, also taking about 25 milliseconds, fortifies the data's security. This stage involves HTTPS and TLS 1.3 handshakes, where your phone and the server synchronize secret keys, and the server presents a certificate affirming its legitimacy. Subsequent routers only perceive garbled data, rendering the information unreadable.

Should the search be revisited, session resumption can bypass much of this procedure. Until now, all the stages have been proximate to Ananya's location, which sets the stage for the subsequent stages.

The edge server in Mumbai, one among many global edge locations, receives the search request. This edge server filters out malicious traffic using a Web Application Firewall and already hosts images and scripts, thereby avoiding unnecessary data transfer. The search is subsequently forwarded to the data centre, where the live prices and inventory are fetched.

A load balancer then selects one of several identical servers, employing methods like round robin or least connections, to prevent any single server from being overwhelmed. This stage takes another 30 milliseconds, and the search has yet to be executed.

At this juncture, the actual search work commences. The API gateway first verifies the request, checking if the user is legitimate, if the request volume is within acceptable limits, and which service should process the query. It subsequently forwards the search to the search service. The headphones search, being quite common, may already reside in a cache in memory.

If not, the search service queries a search index, which directly retrieves the relevant matches, akin to a database index. Concurrently, separate price and inventory services fetch live prices and stock information. These services operate in parallel, and their results are amalgamated once completed. This stage takes approximately 80 milliseconds.

Finally, the results are transmitted back over the established connection, eliminating the need for a new handshake or lock. The results traverse through the load balancer, the edge, and the routers back to Ananya's phone, where images had already been preloaded. The total elapsed time amounts to 190 milliseconds. Ananya's search did not even pause for a blink.

However, if the search servers were relocated to Virginia, a different outcome emerges. Although the application remains unchanged, the location of the servers significantly impacts performance. The same search from Bengaluru now takes about 770 milliseconds, which is four times slower than its original timing. This disparity can be attributed to the extended round trip times between Bengaluru and Virginia, with each round trip taking approximately 220 milliseconds instead of the earlier 25 milliseconds.

Consequently, the total time becomes substantially longer, underscoring the critical importance of server location in application performance.