Web applications and services are classic candidates for caching when it comes to maintaining application states, for example, keeping session state in-memory. This helps to keep frequently accessed data in memory and thus achieves the aim of overall performance gain. This holds true as long as we are talking about web applications deployed on a single node.
As soon as we start considering distributed architectures where web servers are clustered in a scale-out web farm scenario, things start to get interesting. More specifically for ASP.NET session state caching, when used in a clustered deployment presents a couple of subtle and interesting challenges:
Sticky sessions: Ensuring that a particular (returning) client gets routed to a particular server node is critical because that's where the session information is stored for that user
Performance: If the data/state is persisted in SQL Server repository (to avoid sticky routing), then...