[treis]

This is a ton of effort to save the RTT of sending all the requests to a central server. And it all goes out the window the second you need to call an external API in the processing of your requests. And to get what benefit there may be you need to, more or less, pay for a server in every big city. IMHO, outside of gaming there's no real need for what fly.io does.

For something like this to be useful I think the code would need to be running on the user's network. That would drop server ping to sub 1 ms and open up a whole lot of interesting possibilities. But I don't see what changing server ping from 80 ms to 15ms gets me.

[simonw]

This trick isn't just about geographic distribution - it's most commonly used for classic horizontal scaling, where you use multiple read-replicas to handle more traffic.

[tptacek]

If you're getting 80ms response times for user requests, consistently, then it doesn't change much.

[treis]

80ms is the network latency not response times. That's the number fly.io can change and realistic best case is going from 10-15ish ms staying within a city vs 80ms going to a server on the other side of the US.

[tptacek]

I'm just saying, if your application is already fast for your users --- anything in the ballpark of 80ms is fast enough --- geographically distributing it might not make a big difference. I'm agreeing with the comment (or at least, its subtext).

[simonw]

If all of your users are in the US you won't gain much from geographical distribution. Where this gets really interesting is when you have users all around the world.