Is it possible to use this header to preferentially replay requests against specific instances?
It certainly sounds like it.
From the most recent blog post: Globally Distributed Postgres · Fly
It should work with other databases too! There’s no reason we can see why you can’t use the same trick to get MySQL read replicas working this way. If you play around with doing that on Fly.io, please tell us about it at our community site.
It doesn’t sound specific to databases, sounds like you could throw your http requests wherever you want. That’s my interpretation anyway.
You can’t (yet) specify a specific VM with the replay header, but we have plans! If you have something interesting you want to do with it we can probably expose that pretty quickly.
Right now you can send your requests to whichever region you want, but that’s as granular as it gets.
Today I have an application that starts a job that takes some time to complete. While the job is in progress I need to forward all requests related to that job to the instance doing the work.
I do this today with consul locks that include information about the internal instance address that’s doing the work and then adhoc in-app relaying.
What I have now seems to work but feels a bit fragile/non-optimal…
Oh that sounds super interesting. Let me go hustle people to see how quickly we can add instance targeting. 
@ajbouh We just released this. You can now set:
fly-replay: instance=<id>
Give it a try and see if it does what you’re after?
1 Like
What happens if that instance is no longer available? (For example due to a deploy that just happened)
It will retry for a while and then return a 502 HTTP error status.
What about if I set a region and an instance?
The most specific one has priority: instance. There is no retry to the region.