Elaborando meu comentário e assumindo que você não está pensando em algo muito esotérico ...
Talvez você esteja olhando para esse diagrama e o interprete como se os usuários estivessem usando um aplicativo que pudesse conversar com qualquer JVM no backend a qualquer momento durante uma sessão devido a algum tipo de coordenação entre as JVMs. Não é assim que normalmente funciona ... pelo menos não em arquiteturas amplamente usadas.
O diagrama quase certamente representa um ambiente distribuído clássico com JVMs independentes. Se o cliente (o aplicativo do usuário) exigir que esse estado seja mantido entre pedidos (uma sessão ), haverá várias opções, mas todas elas ainda envolverão JVMs sem conhecimento de outras JVMs.
A maneira mais direta e comum de fazer isso é usar um balanceador de carga que suporte as chamadas sessões fixas . Resumidamente, isso significa que, uma vez que o cliente tenha estabelecido identidade , o balanceador de carga sempre roteará os pedidos do cliente para a mesma JVM pela duração da sessão (por exemplo, até que o usuário efetue logout).
O que quero dizer com identidade ? Geralmente, isso significa que o usuário efetuou login e foi autenticado com êxito, após o qual um ID exclusivo será escolhido e associado a todas as solicitações subsequentes do usuário. No caso de aplicativos da Web (como aqueles que usam uma API RESTful), esse ID geralmente é passado por um cabeçalho HTTP. Usar um cabeçalho como esse facilita para a maioria dos balanceadores de carga extrair o ID.
Como alternativa, você pode abrir sessões fixas e armazenar o estado da sessão em um banco de dados, por exemplo, e exigir que uma JVM pesquise esse estado usando a ID da sessão sempre que uma solicitação for recebida. Isso adiciona alguma complexidade e sobrecarga, mas não é inédito. As JVMs ainda são independentes nesse modelo.
(Você também pode fazer com que o aplicativo cliente passe o estado da sessão em sua totalidade em todas as solicitações feitas, mas há problemas de segurança com isso, entre outros problemas.)