Everyone knows that when we travel, the physical distance we must traverse is a determinate factor in how long it will take for us to reach our destination. We travel highways by car, or go by rail, or fly. By car, we can use maps to plot the shortest, fastest route. By rail or flying, it’s a more complicated equation: we must travel from our home to a hub, then travel by rail or train to another hub, then travel from that hub to our destination.
It can even be more complex: you might drive from your home to a train station, take one or more trains to an airport, take a connecting flight to a major airport hub, have a connecting flight at another air hub, get to your destination hub, and then have to reverse the entire process in order to reach your final business destination. All of these hub-related exchanges involve time and scheduling problems. Who hasn’t waited in an airport between connecting flights for inordinate spans of time?
The passage of data packets over the Internet is similar: your data packet can experience delays anywhere among the servers that link your device to your destination server; and delays can also occur on the return trip for your data response. Certainly, the passage of data packets across the Internet has some relation to the physical distance between the sending and receiving device (the drive-by-car or “as the crow flies” representation). However, the complexity of the Internet is much better represented by the complex car/rail/air multi-step hub model.
What this means is that a user’s call from their local platform (phone, tablet, computer) to your API or product is a multi-step process that includes the user’s local Internet facility, the integration of their Internet provider with major high-speed Internet hubs, and the same on the other end of the trip (how fast and robust is your own service’s Internet connection, for example?).
Example: World Bank Countries API Called from around the Globe
To illustrate this, I created API monitors that call the World Bank’s Countries API from four different locations: Ireland, Oregon (U.S. West Coast), Tokyo, and Washington, D.C. (U.S. East Coast). All four monitors request the World Bank information for Brazil.
If your product is significantly based on the World Bank’s API, and you have a single data center located in Washington, D.C. (where the World Bank data center is located), then you can expect the delay users experience when making requests to your app to be primarily related to their Internet distance from Washington D.C. The transaction time between your D.C. data center and the World Bank’s API will be minimal.
The plot below illustrates the timing for calls to the World Bank Countries API from various locations:
This data illustrates that if the World Bank Countries API is a core component of your product, where your product is called from will significantly affect the performance your customers perceive. To retrieve the requested information when calling your product from Oregon or Ireland, the customer will experience a delay of about 350 milliseconds, while a customer calling your product from Japan will experience almost twice the delay. Meanwhile, a customer in Washington, D.C. will receive their data more or less instantaneously.
This is one reason why companies set up data centers across the globe. “Internet distance” is a key component in the response users perceive when they use modern API-based applications.