Fly's multi-region capability is BGP Anycast-based, which is vastly superior (and much more complex to deploy, outside of Fly) to DNS-based solutions like GeoDNS.

One example of app-level tooling is the fly-replay header, which permits your app to automatically replay requests in different regions. This works really well alongside the FLY-REGION environment variable that is available to each node. https://fly.io/docs/reference/fly-replay/

Another example of app-level tooling is the availability of NATS Jetstream, a key/value store that is less feature-rich than Redis, but supports multi-region active/active replication. This is a big deal, as Redis doesn't offer it at the free tier, and many others (KeyDB) who advertise it seem to have trouble delivering it when there's more than two regions in play.

Would have been a good comment if you dropped the first line.

So you disagree that it's superior? Please explain why.

The comment has been deleted to remove the unnecessary comment: you're seeing the improved version.

GeoDNS is a technology that allows you to point web users to a nearby server. That's great, but you still need to coordinate each server. For instance, if you have distributed app servers and a single database server, you still have long distance communication/slowness whenever you need to run database queries.

One solution to this problem that Fly provides app-level support for is to allow you to have a fast local read-only copy of your database on/near each server, so that only inserts/updates need to run remotely. Your regional copies basically fail whenever there's an update, and Fly's platform re-runs the request on the leading webserver (which replicates the update to the regional database servers).

How well does it work? Never used it. But it would save you the trouble of having to notice the problem, come up with a solution and then implement it.