チャットサービスの構築は、思ったほど簡単ではありません。
私は完全なXMPPサーバー、クライアント、およびSDKを構築し、発生する微妙で困難な問題のいくつかを証明することができます。ユーザーがお互いを見てチャットするプロトタイプは簡単です。アカウントの作成、セキュリティ、検出、プレゼンス、オフライン配信、およびフレンドリストを備えたフル機能のシステムは、はるかに困難です。次に、それを任意の数のサーバーに拡張することは特に困難です。
PubSubは、チャットサービスを構築する従来の手段ではなく、チャットサービス（XEP-60を参照）によって提供される機能です。魅力はわかりますが、PubSubには欠点があります。
あなたへのいくつかの質問：
-
これをWeb経由で行っていますか？ユーザーは接続して長時間ポーリングする予定ですか、それともWeb Socketsソリューションを使用していますか？
-
何人のユーザー？ユーザーあたりの接続数は？読み取りに対する書き込みの比率？
-
SQSをそのように使用するというあなたのアイデアは興味深いものですが、おそらく拡張性はありません。チャットサーバーに5万人以上のユーザーがいることは珍しいことではありません。各ユーザーの各SQSキューをポーリングしている場合、その近くに到達することはありません。サーバーごとにキューを用意しておくと、サーバーはそのキューのみをポーリングする方がよいでしょう。次に、ユーザーがどのサーバー上にあるかを把握し、メッセージを適切なキューに入れるのはあなた次第です。
次のようなことをしたいと思うでしょう：
- バックエンド上の大きなRDSデータベース。
- クライアント接続を処理する一連のフロントエンドサーバー。
- すべてを追跡し、メッセージを適切な場所にルーティングする一部の中間層Java / C＃コード。
チャットサーバーの構築の複雑さを理解するには、XMPP RFCの：RFC 3920RFC 3921
をお読みください。