Sticky sessions?

[peterseibel]

This post from a few years ago mentioned that stick sessions were on the roadmap:

Session affinity ("sticky sessions")?

Incidentally, session affinity is on our todo list, we’re just really hesitant to add cookies to peoples’ requests.

I can’t find anything about that in the docs but maybe I’m missing it. Has that been implemented?

[ezbaze]

I think this might be what you’re after:

Dynamic Request Routing

This should be helpfull as well:

How to set up session affinity with nginx for socket.io

TL;DR: you might not even need nginx, fly-replay will likely do what you want. This may turn out to be way simpler than you think. I have an application where requests have affinity - the details are quite different, but the result is the same. But first, let me back up. Request come into the fly network and are handled by one of our edge servers. We have no control over where the come in. We route those requests to the nearest server that you have deployed your application. The result is…

[peterseibel]

Hmm, if I’m reading that right that causes a request to be replayed against another VM which isn’t quite what I’m looking for. I want to arrange things so if a browser gets routed to a given VM on request one subsequent requests go to the same VM. (This is because the app I’m using involves uploading some data to the server and then making a request that processes the data. The data doesn’t have to stick around forever but if the second request goes to a different VM the uploaded data won’t be there.)

I guess I could use replay to replicate the data to all my VMs somehow but that seems a bit excessive.

[rubys]

I’ll start by saying that I agree that ideally this should be handled by the platform, and perhaps some day it will be. Meanwhile…

Consider a deployment with two VMs: VM1 and VM2.

A POST request comes in with some data. It gets routed to VM1. That VM writes the data to the filesystem. Before responding it gets FLY_MACHINE_ID from the ENV and adds it as a cookie.

Subsequently a GET request comes in requiring that same data. Unfortunately it gets routed to VM2. VM2 compares the cookie against FLY_MACHINE_ID and sees that it is different. So instead of proceeding, it responds with a Fly-Replay header specifying the desired machine. Fly.io replays the same get request, but this time on VM1, which successfully processes the request.

[peterseibel]

Ah, I see. So that requires changing the server running on the fly machine to take part in this protocol.

One question though: when VM2 responds with the Fly-Replay header does that cause fly to replay to a new machine and then send the response from the replay back to the original client?

[rubys]

Correct. I should have spelled this out more completely.

The fly proxy that receives the response from VM2 will replay the original request (not the response it just received) to VM1. VM1 will compare the cookie to the FLY_MACHINE_ID, and seeing a match will proceed to read the file (which is only available on this machine), produce a response, and that response will go back to the original client without involvement by VM2.

This isn’t something that I merely think should work, nor is it something that I merely heard others say they use; I this is one of a number of techniques I use actively myself to solve a similar problem:

Showcase architecture - Multiple regions

[peterseibel]

Cool, thanks. Somehow I had missed that the response to the client came from the replayed request rather than the original request. In retrospect that makes sense but the docs could possibly be more clear about that.