Construir um serviço de chat não é tão fácil quanto você imagina.
Construí servidores, clientes e SDKs XMPP completos e posso atestar alguns dos problemas sutis e difíceis que surgem. Um protótipo onde os usuários se veem e conversam é fácil. Um sistema completo de recursos com criação de contas, segurança, descoberta, presença, entrega offline e listas de amigos é um desafio muito maior. Em seguida, dimensionar isso em um número arbitrário de servidores é especialmente difícil.
PubSub é um recurso oferecido pelo Chat Services (consulte XEP-60) em vez de um meio tradicional de construir um serviço de chat. Eu posso ver o fascínio, mas o PubSub pode ter desvantagens.
Algumas perguntas para você:
-
Você está fazendo isso pela Web? Os usuários vão se conectar e fazer long-poling ou você tem uma solução de Web Sockets?
-
Quantos usuários? Quantas conexões por usuário? Proporção de gravações para leituras?
-
Sua ideia de usar o SQS dessa maneira é interessante, mas provavelmente não será dimensionada. Não é incomum ter 50k ou mais usuários em um servidor de bate-papo. Se você estiver pesquisando cada fila SQS para cada usuário, não chegará nem perto disso. Seria melhor ter uma fila para cada servidor, e o servidor sonda apenas essa fila. Então cabe a você descobrir em qual servidor o usuário está e colocar a mensagem na fila certa.
Eu suspeito que você vai querer algo como:
- Um grande banco de dados RDS no back-end.
- Um monte de servidores front-end que lidam com as conexões do cliente.
- Algum código Java/C# de camada intermediária rastreando tudo e roteando mensagens para o lugar certo.
Para ter uma ideia da complexidade de construir um servidor de chat leia as RFC's do XMPP:RFC 3920RFC 3921
