By implementing load balancing and distributing the traffic to multiple instances running our application, we introduce better resiliency and higher availability, but, as a drawback, we also introduce complexity as far as maintaining session state is concerned. In a single server setup, the application can easily maintain the state of the application; since all connections are received by the server, the application has a complete picture of incoming requests. When we implement a load balancer, the load balancer receives the connections and forwards the requests to multiple servers running the application, causing each application part to only be able to see the traffic to itself. When a load balancer detects an instance with a high load, it will try to redirect the users to another instance and if we maintain the session state in the application, the new node would not be able to know the previous session state and would restart the session.

One way we can avoid this situation is by delegating the load balancer with session persistence by implementing sticky sessions. This allows the load balancer to always direct the user to the same server that created the application cookie. This allows us to use a distributed environment, but still maintain the session state within the application. The drawback is that the load on the servers will eventually become uneven, especially when we have sessions of different lengths. Also, a failure of one of the instances in the backend will inherently mean all its sessions will be reconnected, as the session state within the application on that instance is lost.

To mitigate the limitations of the sticky session approach, we should always strive to maintain the session state outside the application. In AWS, we can use an ElastiCache cluster or a DynamoDB table to record the session state. This way, all the instances in the target group of the load balancer can record session information in a highly available location that is accessible to all nodes. Any node receiving a connection can now consult the data in ElastiCache or DynamoDB and evaluate whether this is a new or an existing session, and if it is an existing session, what the state is at this time. This way, we can easily distribute the traffic over the instances evenly and survive any instance failures without affecting the clients.