From time to time, we get asked why we route a certain country or region to a PoP that's not geographically closest to the end-user. After all, that's what CDNs are all about, accelerating content and caching on the edge.
The answer is pretty simple, but to understand the problem better, let's look at how the internet works. In a very simplified manner, the internet is a collection of fiber, wires and networking equipment connected to each other around the world.
Different internet providers in different countries have different connections between each other and even in a case where there is a potential connection between two regions, there is a chance that the ISP might not have access to that connection.
This can be nicely illustrated with the global submarine cable map provided by submarinecablemap.com:
For example, even though Brazil is geographically quite close to Africa, there's actually a very limited connectivity between these two regions and there's a high chance a connection from Brazil would first need to reach North America, then Europe and only then be on it's way to Africa.
To illustrate this in action, here's a network path from our Sao Paulo PoP going to our PoP in Lagos. It's first stopping for some sightseeing in New York, then visiting London for a bit. Only after over 142.5ms the first packets will reach their destination after travelling thousands of kilometers around the world:
traceroute -I 126.96.36.199 traceroute to 188.8.131.52 (184.108.40.206), 30 hops max, 60 byte packets 1 * * * 2 10.10.0.2 (10.10.0.2) 0.387 ms 0.400 ms 0.401 ms 3 172.30.30.9 (172.30.30.9) 0.619 ms 0.857 ms 0.867 ms 4 10ge0-1.core3.sao1.he.net (220.127.116.11) 127.126 ms 126.937 ms 127.131 ms 5 100ge8-1.core1.nyc4.he.net (18.104.22.168) 126.928 ms 126.959 ms 127.166 ms 6 100ge7-1.core1.lon2.he.net (22.214.171.124) 192.323 ms 192.363 ms 192.365 ms 7 hurricane-ic-129713-ldn-b5.c.telia.net (126.96.36.199) 192.482 ms 192.772 ms 192.720 ms 8 west-indian-ocean-cable-company-ltd.10gigabitethernet5-3.core1.lon3.he.net (188.8.131.52) 193.320 ms 192.022 ms 192.094 ms 9 184.108.40.206 (220.127.116.11) 192.653 ms 193.109 ms 193.116 ms 10 18.104.22.168 (22.214.171.124) 284.804 ms 284.856 ms 284.803 ms 11 126.96.36.199 (188.8.131.52) 285.115 ms 285.080 ms 285.084 ms 12 184.108.40.206 (220.127.116.11) 285.081 ms 285.080 ms 285.069 ms
While this is an extreme example to illustrate the problem, the same issue happens regularly in real-world scenarios between different countries and regions. This happens especially often in less developed regions where many datacenters are connected in a way that they're only really useful to serve a single country.
The good news is that most network administrators are well aware of these problems. At bunny.net, we are constantly monitoring network routes and optimizing both the carrier selection and the routing itself to make sure we're always serving the end-user with the most optimal path.
In some regions like Singapore, we actually opened multiple PoPs with a different networking blend to ensure we can serve content as effectively as possible for nearby countries. As another example, we can also have a look at our recently opened PoP in Nigeria, which is configured to only serve users from within the country to avoid any long holiday trips like the example above. Nearby countries such as Ghana or Mali are on the other hand served by our Madrid or Paris PoP that are much better connected for these regions.
So if you ever wonder why you're being routed to a specific location that might not seem like the ideal destination at first, there's a high chance it simply offers a better route for your specific ISP.
Of course, no system is perfect and networks are changing day to day. While we do our best to stay on top of everything, don't be afraid to let us know something is off and our team will make sure to look into it.
Are you curious about routing yourself? Run a traceroute to bunny.net and see this in action.