En primer lugar, su diagrama supone que el equilibrador de carga está actuando como un (TCP) proxy de, que no es siempre el caso. A menudo, se utiliza el enrutamiento directo (o el retorno directo del servidor) o se realiza el NAT de destino. En ambos casos, la conexión entre el servidor de fondo y el cliente es directa. Entonces, en este caso, es esencialmente el protocolo de enlace TCP el que se distribuye entre los servidores back-end. Véase lo siguiente para más información:
Obviamente sí existen servidores proxy TCP (HAProxy ser uno), en cuyo caso el proxy maneja ambos lados de la connecton, por lo que su aplicación necesitaría poder identificar al cliente por la IP/Puerto entrante (que sería del proxy en lugar del cliente). El proxy gestionará la devolución de los mensajes al cliente.
De cualquier forma, todo se reduce al diseño de la aplicación ya que me imagino que el truco es tener una tienda de sesión común (una base de datos de algún tipo, o clave => almacén de valores como Redis), de modo que cuando su servidor de aplicaciones dice "Necesito enviar un mensaje a Frank", puede determinar a qué servidor back-end Frank está conectado (desde DB) y le indica a ese servidor que le envíe el mensaje. Se reduce el problema de las conexiones (del mismo cliente) moviéndose por diferentes servidores backend al tener conexiones persistentes (todos los equilibradores de carga pueden hacer esto), o usando algo intrínsecamente persistente como un websocket.
Esto es probablemente una gran simplificación ya que no tengo experiencia con el software de chat. Obviamente, los propios servidores DB se pueden distribuir entre varias máquinas, para la tolerancia a fallas y el equilibrio de carga.
Con carga equilibrada en un diseño paralelo como el que presenta, tiene algunos problemas, como habrás notado. Tome IRC en su lugar para un ejemplo, que tiene un diseño de árbol (esto ayuda a la sincronización y simplifica la entrega de mensajes a todo el mundo), y la masa de datos que pasa por el árbol no es demasiado, de acuerdo con, por ejemplo, freenode ops, a pesar de sus casi 80k usuarios. –