An ASP.NET State is used to keep data across a sequence of user requests to the server. This Session State is usually maintained from the first user request until a specific period after the user's last request, usually around 20 minutes.

If your application is running on only one server, you can use the standard ASP.NET Session State without any problems. However, if you want your application to run in a server-cluster/server-farm, then you need to make sure that either the Session State is available from all the servers in the farm or you use "sticky sessions" feature of your load-balancer.

The problem with sticky sessions is that they limit your application scalability because the load balancer is unable to truly balance the load each time it receives request from a client. With sticky sessions, the load balancer is forced to send all the requests to their original server where the session state was created even though that server might be heavily loaded and there might be another less-loaded server available to take on this request.

ASP.NET provides a mechanism for you to share Session State throughout the cluster. But, it has its own scalability problems. ASP.NET allows you to either point all your servers in the server-farm to one particular server for Session State or point them all to a SQL Server. Both of these approaches force you into a single-point-of-failure scenario and they're also not very scalable because all the load of accessing the Session State is shifted to one server.

The answer to all of this is to have Session State truly clustered. This way, it does not matter on which server the session was actually created because the session lives in the entire cluster. The user request can then be forwarded by the load-balancer to the most appropriate server. This approach is also highly scalable and there is no single point of failure.