Multiple frontends, shared backend and dealing with concurrent requests attached to one session

Let say I have a simple architecture where sessions would be shared through a database, with multiple frontends (say F1 and F2) speaking to the same backend.

My issue is the case where both frontends would receive a request corresponding to a same session: a naive implementation would cause session to overwrite each other (I looked at django which seems to fall into that case). I could try to design the backend such as it garantees that no more than one frontend can deal with a given session, but this seems hard to do correctly, especially if I want to handle frontend failures.

I can't help but thinking that the case is pathologi开发者_高级运维c in the first place (there should not be more than one request for a given session at any time), and is not worths being dealt for, but I have not much experience in web development, so maybe I am missing something. How does one usually deal with this case ?

Possible solutions that I would like to avoid:

• Sticky session: that's the solution I currently use, and is difficult to support once you have several load balancers, and more significantly goes against the spirit of load balancing in the first place.
• Putting data in cookie: for technical reasons outside my control, I cannot use cookie.

One common solution is known as session persistence. Whatever routes your request to the f1 or f2 ensures that as long as a session is active, the client with that session only goes to one frontend.

It is a common feature in almost all loadbalancers. For example, nginx has the ip_hash http://wiki.nginx.org/NginxHttpUpstreamModule