最もスケーラブルなソリューションは、あなたが除外したソリューションです。つまり、ノードを好きなだけ持つことができる共有状態のない単一層の Web アプリです。ロード バランサーの背後にあるn 個の Web サーバーとm 個の分散データベース ノードほどスケーラブルなものはありません。最もスケーラブルなアーキテクチャを除外したため、おそらくスケーラビリティを求めていないため、間違った質問をしています。おそらく、可用性などの他のアーキテクチャの原則を見ているでしょう。
複数のサービス間で機能を分離するのはなぜですか? 多くの理由があります。非同期処理により、可用性が向上します (キューに書き込み、障害を気にしないことにより)。また、データベースなどのボトルネックを管理することもできます。また、開発、展開を容易にするために、アプリケーションをサービスに分割します。したがって、可用性、保守性、セキュリティ、パフォーマンス、展開性、コスト、使いやすさ、テスト容易性、コンプライアンス、またはその他の何かを求めている可能性があります。スケーラビリティ ハンマーをつかむ前に、その質問に自分で答える必要があります。私は、これらの難しい質問を問いかけ、それに答えるために、特にCALMを作成しました。
質問の詳細に戻ります。Windows Azure で一般的にスケーラブルな (それが本当に必要な場合)事実上の非同期処理パターンには、WCF が含まれていません。WCF には特定の理由がありますか? WCF と Service Bus が必要でない場合、不必要に複雑になるため、良いものである必要があります。Windows Azure では、(MVC アプリをホストする) Web ロールを使用して非同期処理を実装し、Windows Azure キューにメッセージを配置します。これらはワーカー ロールによって処理されます。クライアント (ブラウザー) に結果を知らせる必要がある場合は、CQRS パターンを手動でロールするか、他の人が言及したように SignalR を使用できます。私はWCFを取り除くことを真剣に考えています。
あなたのシナリオに関して：
シナリオ 0:
ステートレス Web サーバーがすべての処理を行い、分散データベース ノードと直接通信します。これは最もスケーラブルですが、他にも欠点があります。
シナリオ 4:
フロント エンドがメッセージを Azure キューに配置し、結果をクライアントに返します。Worker ロールはメッセージを処理し、結果をどこかに置きます(テーブル ストレージまたは BLOB)。ブラウザの Javascript は結果データをポーリングし、「完了」するとクライアントに提示します。これはCQRSっぽいです。（ダンリーの答え）
シナリオ 5:
フロント エンドがメッセージを Azure キューに配置し、結果をクライアントに返します。ワーカー ロールはメッセージを処理し、結果を SignalR 経由でクライアントに送信します。（jgauffinの答え）
シナリオ5の方がいい