8 tips to consider

Best practices in geolocation-based API request routing

Manjula Rathnayake
© Shutterstock / Hurst Photo

With geolocation-based API request routing, the geographic location from which the request originates is mapped to an API gateway residing in one of the configured regions. Follow these geolocation best practices.

The rapid growth in API consumers means companies increasingly need to manage their requests based on location. With geolocation-based API request routing, the geographic location from which the request originates is mapped to an API gateway residing in one of the configured regions, ideally near the requester. By exposing APIs on multiple gateway locations in this way, companies can reduce their network overhead, maximize the scalability of services, and facilitate regional compliance.

SEE ALSO: What does Serverless have in common with Nutella?

A major driver for geolocation-based API request routing is the growing trend toward hybrid API management, which has given providers more freedom to deploy gateways in multi-cloud, multi-regional data centers. As the business grows, and more APIs are consumed from various locations, users start experiencing latencies that manifest as slow page loads.

Usually, the latency is caused by network overhead across the consumer, API gateway, and backend services. Using analytic tools supported by management solutions, API providers can identify the network overhead and originating IP addresses of consumers. These statistics reveal the need for multi-regional API gateways and backend service hosting on multiple data centers.

Data access regulations and privacy policies also create demands to drive server traffic and data from regional data centers. For example, different governments’ laws on content-sharing prohibit media content providers from distributing in certain regions.

Another factor is the nature of data exposed through an API. For instance, with an API for advertising data, responses are filtered by the requesting user’s geolocation, age, etc. While it is designed with the location as a request parameter, backend services usually validate it with the requestor’s resolved geolocation.

Regardless of the application, a general concept of geolocation-based request routing is that the geographic location from which a request originates is mapped to an API gateway residing in one of the configured regions, preferably to the region closest to where the request originated. In implementing geolocation-based request routing, there are eight best practices to consider.

The first step is understanding the need to implement geolocation-based API request routing. The load balancer and API gateway-level complexity for enabling geolocation routing may be minimal, but data synchronization among data centers hosting the backend brings complexity. Even if data synchronization is not essential, the cost of managing multiple data centers is high.

For most API projects, the geolocation-based routing is an iterative process as consumers are identified in multiple geolocations. To reduce the latency, you can first consider enabling caching and performance optimization of the backend services and then consider providing data centers closer to consumers.

An API requestor’s geolocation is identified by mapping the IP address. The IP is detected using the source IP address of the DNS query it receives and the client subnet address. The client subnet address is identified through the Extension Mechanisms for DNS (EDNS0). Because a client’s geolocation cannot always be accurately detected, mapping a default routing path for such requests is essential.

If the accuracy of the geolocation is critical to the nature of an API, then its backends should validate users with JWT, not just rely on the geolocation. The cache time of a DNS query response (time to live) should be set to a value, like 1 minute to prevent overloading the DNS server and avoid caching outdated values if there is a DNS change of gateways.

All the regional gateway load balancer IPs and failover IPs should be shared with clients because most of the clients whitelist these IPs in the firewall.

To increase security for certain APIs, client IPs should be whitelisted at the gateway load balancer. Some organizations prefer mutual SSL to whitelist API clients. Either way, it is essential to propagate rules and certificates to all regional and failover gateway load balancers.

SEE ALSO: Angular Monorepo Diaries

Finally, people move around. For that reason, the preferred way to simplify client application development is by using a global endpoint as the API access URL instead of having regional URLs. That way, for example, when mobile application users travel, they receive data pertinent to the region they visit.

Following these geolocation best practices will ensure that consumers get fast, relevant responses to their requests.


Manjula Rathnayake

Manjula Rathnayake is an associate director and software architect at WSO2. He had the opportunity to work with multiple products in Integration and IAM domains. He is mainly responsible for hosting and maintaining the Public Cloud offering of WSO2. He holds a B.Sc in Engineering from the Department of Computer Science & Engineering of the University of Moratuwa, Sri Lanka.

Inline Feedbacks
View all comments