Clustering

La manera en que funciona el cluster es que tienes al frente un balanceador de cargas. Cuando llega una petición, la envía al servidor que menos carga tiene (idealmente) o al que sigue (con algoritmo de hacer rondas, lo más común) o a uno al azar (subóptimo). Cuando son peticiones que no tienen sesión, es decir no se genera una sesión y no había una sesión previa, entonces no se tiene que guardar nada de estado en el servidor ni en el balanceador y por lo tanto la siguiente petición puede llegar a cualquier otro server.

En el momento en que tu aplicación le genera una sesión a una petición, hay de dos sopas cuando estás en cluster: Una, que la sesión solamente existirá en ese server y por lo tanto ese cliente ya tiene que conectarse siempre a ese server (el cliente no sabe cómo, eso es chamba del balanceador de cargas, y para poder hacer eso tienen que pegarle cosas al URL). Dos, que las sesiones se replican entre todos los servers que conforman el cluster, para que la siguiente petición del mismo cliente pueda llegar a otro server y ahí se encuentra una copia de su sesión. Pero cada vez que se modifica la sesión hay que replicarla entre todos los servers del cluster, por lo que se empieza a generar mucho tráfico interno y al final no es tan escalable porque todos los servers terminan teniendo todas las sesiones existentes y eso ocupa bastantes recursos, deben tener muchísima memoria aunque no tengan tanto CPU.
Con el enfoque de que la sesión se queda en el mismo server siempre, es un poco más escalable siempre y cuando haya un uso uniforme, en el sentido de que todos los clientes usan la aplicación de forma similar, por lo que el balanceador de cargas terminará enviando clientes nuevos a distintos servers y al final cada uno tendrá aproximadamente el mismo número de sesiones activas. Pero puedes correr el riesgo de que de repente un nodo del cluster (un server pues) está atascado de sesiones mientras que otros casi no tienen.

Cada enfoque tiene sus ventajas y desventajas, cuando manejas sesiones. Si no manejas sesiones, entonces no tienes bronca porque cualquier cliente puede ser atendido por cualquier nodo del cluster, todo el tiempo, lo cual hace la repartición de trabajo más uniforme entre los nodos.

Si tu aplicación necesita generar una sesión, pues ni modo... pero si solamente guardas ahí un dato o dos, puedes mejor usar cookies y con eso ya no generas sesión, simplemente el nodo que atienda la petición debe obtener la cookie para saber si el usuario ya tiene datos de una interacción previa o no. Generalmente guardas por ejemplo llaves de algunos datos y vas por esa info a la base de datos en cada petición (esa es la desventaja del uso de cookies). Esto lo puedes aliviar si tienes suficiente hardware, haciendo que tu base de datos tenga replicación, incluso puedes tener (dependiendo de tu app) un solo maestro y varios esclavos de sólo lectura; los esclavos son usados para las consultas por cualquier nodo, pero todos los nodos escriben al mismo server de base de datos (al maestro).

Entiendo que la recomendación es utilizar la sesión lo menos que pueda, incluso no usarla lo cual implica estar pasando id entre los request y haciendo consultas....
Igual entiendo que puedo subir muy poquitos datos a la sesión y replicarla en todos los servers, creo que este es el mejor esquema cierto ?

Sin embargo casi todas las aplicaciones usan una sesión desde el momento que se logea un usuario y se sube a ella no (al menos en mi experiencia es lo que siempre he visto) ? Esto cómo se puede solventar ?

Si no quieres sesiones entonces no uses getSession() o si lo usas, hazlo con el parámetro boolean, getSession(false) para que no se genere una sesión si todavía no existe.