I’m working on a app that runs across multiple regions, with 2 instances in each region, giving me a total of 6 servers (e.g., Amsterdam-1, Amsterdam-2, Singapore-1, Singapore-2, etc.). By default, Fly.io’s Anycast routing sends users to the nearest server based on latency, but I want to allow my users to explicitly select which server they connect to.
Here’s what I’m looking to achieve:
1. Provide users with a UI to select their preferred server.
2. Route their traffic to the specific instance they choose (e.g., Singapore-1).
3. Persist the user’s selection for future requests (e.g., via cookies or headers).
4. Handle edge cases like server unavailability and ensure proper fallbacks.
Additionally, I’d love to hear how others have handled similar setups:
• How do you ensure health checks and fallbacks for user-selected servers?
• Any tips on scaling effectively while managing server preferences?
Thanks in advance for any insights or suggestions!
One option is to use the fly-force-instance-id header in client requests which will force the proxy to send the request to a particular machine. Do note that if the machine is unavailable the proxy won’t try any other machines.
The most general solution is to have two apps: one for routing requests and one for your application. If the router uses a reverse proxy, it can even examine responses and recover from failures.
I’ve expressed a wish for a fly-prefer-instance-id header that behaves like fly-prefer-region in that it routes requests that can’t be satisfied anyway, giving the recipient an opportunity to either take corrective action or at a minimum produce a better error response. If others have an interest in this, let us know.
I’ve written up how I approach this problem for my showcase app, and I’m actively working to extract this code into a reusable library. It is not ready yet, but I have a Rails demo and am now looking at what it would take to support various JS Frameworks.