Crear un servicio de chat no es tan fácil como parece.
He construido servidores XMPP completos, clientes y SDK y puedo dar fe de algunos de los problemas sutiles y difíciles que surgen. Un prototipo donde los usuarios se ven y chatean es fácil. Un sistema de funciones completas con creación de cuentas, seguridad, descubrimiento, presencia, entrega fuera de línea y listas de amigos es un desafío mucho mayor. Luego, escalar eso a través de un número arbitrario de servidores es especialmente difícil.
PubSub es una característica que ofrecen los servicios de chat (consulte XEP-60) en lugar de un medio tradicional de crear un servicio de chat. Puedo ver el atractivo, pero PubSub puede tener inconvenientes.
Algunas preguntas para ti:
-
¿Estás haciendo esto a través de la Web? ¿Los usuarios se conectarán y harán largas consultas o tiene una solución de Web Sockets?
-
¿Cuántos usuarios? ¿Cuántas conexiones por usuario? ¿Proporción de escrituras a lecturas?
-
Su idea de usar SQS de esa manera es interesante, pero probablemente no escalará. No es inusual tener 50k o más usuarios en un servidor de chat. Si está sondeando cada SQS Queue para cada usuario, no se acercará a eso. Sería mejor tener una cola para cada servidor, y el servidor sondea solo esa cola. Luego depende de usted averiguar en qué servidor está un usuario y colocar el mensaje en la cola correcta.
Sospecho que querrás hacer algo como:
- Una gran base de datos RDS en el backend.
- Un montón de servidores front-end que manejan las conexiones de los clientes.
- Algunos códigos Java/C# de nivel medio rastrean todo y enrutan los mensajes al lugar correcto.
Para tener una idea de la complejidad de construir un servidor de chat, lea los RFC de XMPP:RFC 3920RFC 3921
