0

I am very new to this field, so my wording may not be spot on.

My crypto exchange offers an API, and I stumbled upon the question when I was playing with it on AWS Cloud9 where I can change client's regions by switching EC2 instances.
I was measuring latency(*1) of several REST API requests from different client's regions.

(*1) I measured a time difference between when a client request.get/post and when a client received json payloads in milliseconds.

Below is what I got.

Client's region API endpoint 1 API endpoint2
Tokyo 100ms 150ms
California 30ms 500ms
Frankfurt 15ms 700ms

From the result, I understood that API Server for endpoint1 and endpoint2 are located in different regions, which means that the company have multiple server locations for a single domain.

What are the benefit(s) of having servers ( or specifically, API Servers) in different locations for a single domain?

koyamashinji
  • 103
  • 3

1 Answers1

0

You've already almost answered your question. In general the benefit are in having lower latency responses. While having those on the same domain might sound that you can't pick closest server it's not true. There are techniques that can handle that.

One of them is having your DNS servers to respond with endpoint IP that matches closest one to the IP-based geolocation of the client. That won't always work because you can use some weird DNS server which aren't close to your geo location. But usually this will work and improve response speed.

Moreover there is a thing such as Anycast or Geocast. Even the same IP could be located on different endpoints distributed geographically for lower latency. Simple example is the Google Public DNS servers. You can ping those and see that the latency will be pretty low from different parts of the world. And if you run a traceroute you can see as it routed through different AS to provide a pretty short routes.

Second benefit are in having redundancy. Shall one of the servers fail, load balancers should direct requests to other. Responses might get slower as you can't pick the closest server, but at least it won't fail completely.

NStorm
  • 1,312
  • 7
  • 18
  • Thanks for the answer. So, if I understood it correctly, and applied it to my example case, the exchange API server fails to realise the said low latency, because the latency is apparently very different depending on the client's regions (Frankfurt being the fastest on average for endpoint 1, and Tokyo for endpoint 2.) If the exchange's DNS server succeeds in realising the said latency, Tokyo, California, Frankfurt each should get similar latency for each both endpoint1 and 2. So it is "using some weird DNS server which aren't close to your geo location"? Is my understanding correct? – koyamashinji Jun 10 '21 at 08:11