Answers: <p>Proxying is gonna cause you some issues when someone takes a trip to China and tries to access data in the USA, depending on what your app does they could cause you some $$$ issues when your Chinese POP is sending/receiving all of their traffic each way.</p>
  
  <p>Instead I suggest:</p>
  
  <p>If your API is authenticated and you're not going to replicate any of the data and you're using AWS then I'd use lambda@edge to do what you need.</p>
  
  <p>You can use GEO-DNS to route to a lambda function which handles authentication. This lambda function can also hold a record of where users need to go and issue a redirect to the correct endpoint.</p>
  
  <p>This does mean that you'll still need domains like <code>api-region3.company.com</code> but it will allow <code>api.company.com</code> to perform the task of being universal. It's down to the client application then to hold on to that URL? At least using redirects instead of proxies should help with network traffic.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-10-11T08:10:51.137Z
Answers: Thank you for your answer. I'm not sure how clients who implemented our API through ex. XmlHttpRequest in JavaScript, will respond to a 3xx redirect suddenly being returned, which is why I was looking into proxying.
Answers: Silas Hansen
Answers: CC BY-SA 3.0
Answers: 2017-10-10T12:21:43.407Z
Answers: 2017-10-10T13:21:03.120Z
Answers: 2017-10-10T13:21:03.120Z
Answers: Briansbum
Body: <p>The data of each customer only exist in one of several global datacenters, that all answer to the same hostname (ex. api.company.com)</p>
  
  <p><strong>Only a single domain for all customers globally</strong><br/>
  I want to make sure that all global customers only have to use a single domain: api.company.com to access their data, and not something like api-region3.company.com, but it may not be possible.</p>
  
  <p><strong>GEO Location DNS may go to wrong datacenter</strong><br/>
  I cannot use geo-location DNS directly, because that would mean that someone might end up accessing a datacenter that does not contain the data for that customer. </p>
  
  <p><strong>Possible solution</strong><br/>
  I could use a proxy at each of the datacenters to relay the request to the correct datacenter, based on some information in the request, but I'm not sure if there's some better established industry standard way of doing this, without duplicating the data across all datacenters. In case proxying/relaying is the best option, what is some tried-and-tested options for actually setting this up?</p>
  
Tags: <amazon-web-services><distributed-systems>
Title: How to route to specific, of multiple datacenters, with a single domain
UserDisplayName: Silas Hansen
ThreadText: # How to route to specific, of multiple datacenters, with a single domain
  
  (Asked by: username_0 on 2017-10-10)
  
  The data of each customer only exist in one of several global datacenters, that all answer to the same hostname (ex. api.company.com)
  
  **Only a single domain for all customers globally**  
  I want to make sure that all global customers only have to use a single domain: api.company.com to access their data, and not something like api-region3.company.com, but it may not be possible.
  
  **GEO Location DNS may go to wrong datacenter**  
  I cannot use geo-location DNS directly, because that would mean that someone might end up accessing a datacenter that does not contain the data for that customer.
  
  **Possible solution**  
  I could use a proxy at each of the datacenters to relay the request to the correct datacenter, based on some information in the request, but I'm not sure if there's some better established industry standard way of doing this, without duplicating the data across all datacenters. In case proxying/relaying is the best option, what is some tried-and-tested options for actually setting this up?
  
  **Tags:** amazon-web-services, distributed-systems
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2017-10-10. Score: 4
  
  Proxying is gonna cause you some issues when someone takes a trip to China and tries to access data in the USA, depending on what your app does they could cause you some $$$ issues when your Chinese POP is sending/receiving all of their traffic each way.
  
  Instead I suggest:
  
  If your API is authenticated and you're not going to replicate any of the data and you're using AWS then I'd use lambda@edge to do what you need.
  
  You can use GEO-DNS to route to a lambda function which handles authentication. This lambda function can also hold a record of where users need to go and issue a redirect to the correct endpoint.
  
  This does mean that you'll still need domains like `api-region3.company.com` but it will allow `api.company.com` to perform the task of being universal. It's down to the client application then to hold on to that URL? At least using redirects instead of proxies should help with network traffic.
  
  > **Comments:**
  > **username_0**: Thank you for your answer. I'm not sure how clients who implemented our API through ex. XmlHttpRequest in JavaScript, will respond to a 3xx redirect suddenly being returned, which is why I was looking into proxying.  
  
  ---
  
  