I'm working on a Desktop App in C# that communicates with a Java backend hosted AWS. I want to deploy on multiple instances and use an Application Load Balancer with sticky sessions but as Far as I know it is based on cookies to route the request.

So far I can only think on 2 solutions :

  1. Handle cookies on my Desktop App, so my question if it is a bad practice
  2. Create my own load balancer on a different instance and route based on an http header.

I would like your opinion about these 2 solutions, which one do you think complies the most with good practices.


1 Answer 1


In principle, there's no problem with using HTTP/REST to communicate between a desktop app and a backend. In that context, it can also be a great idea to use various HTTP features. This might include cookies, though your client code will probably not implement a full-fledged “cookie jar”. And it would be unusual to create a backend API that expects you to use cookies, with Authorization: Bearer TOKEN headers being more common.

What is a bad practice though is sticky sessions. You might want to use sticky sessions when your backend has multiple instances for load-balancing, and each instance stores its own per-session data, in particular if that per-session data is stored in memory. This leads to a host of problems, notably that sessions are logged out if you need to restart an instance, that you can't scale up or down easily, and that it's not fault-tolerant.

Industry best practice very clearly is that such backend instances should be stateless – if they need to persist any data beyond a request, that data should be externalized into a database. Then, you can freely load balance without having to consider which instance handled which session. Consider reading The 12 Factor App, in particular point VI: Execute the app as one or more stateless processes.

I would only consider deviating from this best practice and start using sticky sessions if the API in question is extremely latency sensitive, so that the extra millisecond for connecting to a shared session storage database (e.g. Redis) would be intolerable.

  • Hi, Thanks for your reply, for session replication I use tomcat clusters in a multicast membership, this allows me to keep the same session even if the instance starting it is shutdown Commented Sep 22, 2022 at 7:04
  • 1
    @HichamZouarhi If you use session replication, then you don't need sticky sessions. Note that Tomcat's default session replication is in-memory, and session data will still get lost if the entire cluster shuts down.
    – amon
    Commented Sep 22, 2022 at 8:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.