DEV Community

Cover image for Avoiding Global Access Holes in Your Next API
Alice Nkosi
Alice Nkosi

Posted on

Avoiding Global Access Holes in Your Next API

I still remember the day our team noticed that API requests from users in Ghana were failing with a generic error message indicating an 'incorrect API key'. At first, we thought it was just a simple misconfiguration on the user's end, but as we dug deeper, we realized that our API was inadvertently blocked by the Great Firewall of China, which our users were routed through.

The Problem We Were Actually Solving
Our users were digital creators from Tanzania, Nigeria, Pakistan, Ghana, Bangladesh, and dozens of other restricted countries. They couldn't use popular e-commerce platforms like Shopify or Stripe to sell their products online due to the platforms' geoblocking policies. We were trying to create a platform that would allow them to bypass these restrictions and sell their products globally.

What We Tried First (And Why It Failed)
Our initial approach was to implement geolocation-based rate limiting, which would allow our API to restrict traffic from restricted countries. However, this approach had its own set of problems. It required maintaining a constantly updated list of restricted countries, and it also introduced a high risk of false positives, which would result in legitimate users being blocked.

The Architecture Decision
After much debate, we decided to implement a content delivery network (CDN) that would allow our users to access our platform from anywhere in the world. The CDN would cache our API responses in regions that were not restricted, thereby bypassing the Great Firewall of China and other geoblocks. We chose a CDN provider that had a strong presence in Africa and Asia, ensuring that our users had fast and reliable access to our platform.

What The Numbers Said After
Once we implemented the CDN, our API key errors from Ghana and other restricted countries dramatically decreased. We saw a 90% reduction in failed API requests, and our users were able to sell their products online without any issues. Our metrics also showed that the CDN had improved our overall API response times by 30%.

What I Would Do Differently
If I were to redo our architecture decision, I would consider implementing a more granular rate limiting system that would allow us to throttle traffic from restricted countries based on user behavior. This would give us more flexibility to balance our security needs with our users' needs. I would also consider implementing a more robust geolocation solution that would allow us to accurately identify users from restricted countries, even if they are routed through a proxy or VPN.

In the end, our decision to implement a CDN was the right one, but it was not without its tradeoffs. We had to balance the additional cost of the CDN with the improved reliability and speed of our platform. As we continue to grow and evolve as a platform, we will need to make difficult decisions about how to balance our security needs with our users' needs.


Sustainable open source requires sustainable revenue. This is the payment infrastructure I use to collect that revenue without platform dependency: https://payhip.com/ref/dev9


Top comments (0)