私は、RESTサービスの利点、ステートレス全体、およびセッションアフィニティの「もの」について検討してきました。インフラストラクチャ内の複数のマシンにサービスの複数の展開バージョンがあり、それらがすべて特定のリソースに作用する場合、そのリソースの状態はどこに保存されているのでしょうか。
分散キャッシュを利用する単一のホストと、サービス内で変更される状態をインフラストラクチャに含めることは意味がありますか？それは単にキャッシュをフェッチ/プットしますか？これにより、負荷分散の理由でデプロイされたサービスがいくつでも、リソースの同じ状態ビューをすべて表示できるようになります。
高負荷（通常は高い信頼性を意味します）用のシステムを設計している場合、単一障害点を持つことは決して良い考えではありません。一貫性のあるビューを提供するサービスがダウンした場合、データベースがすべてを照会されるため、せいぜいパフォーマンスが大幅に低下し、最悪の場合、アプリケーション全体が機能しなくなります。
あなたの質問では、あなたは一貫性について心配しているようです。eBayのアーキテクチャについて学ぶべきことがあるとすれば、それは可用性/冗長性/パフォーマンスと一貫性の間で行われるべきトレードオフがあるということです。100％の一貫性は必要なく、少しの「混乱」から逃れることができます。
分散キャッシュ（memcacheなど）は、スケーラブルなインフラストラクチャを作成するために広く使用されている分散ハッシュテーブルのバッキングとして使用できます。正しく実装されている場合、キャッシュは冗長になり、キャッシュは動的にリングに参加したり、リングから離れたりする可能性があります。
ヘッダー（ ETag）とソフトウェア（リバースプロキシとしてのSquidプロキシなど）を適切に使用してHTTPレイヤーをキャッシュできるため、RESTも本質的にキャッシュ可能です。ヘッダーを介してキャッシュを指定することの1つの欠点は、ヘッダーを解釈して尊重するクライアントに依存することです。
ただし、Phil Karltonを言い換えると、キャッシングは困難です。キャッシュするデータ、キャッシュするタイミング、およびそのキャッシュを無効にする方法を選択する必要があります。無効化は、次の方法で実行できます。
実装が簡単なタイマーベースのアプローチに部分的であり、古いデータがシステムに存在する期間を比較的確実に言うことができます（たとえば、会社の詳細は2時間で更新され、株価は10秒で更新されます） 。
最後に、高負荷はユースケースにも依存し、トランザクションの量によっては、これが当てはまらない場合があります。方法論（もしそうなら）は次のようになります：
結局のところ、そもそもパフォーマンスの問題はなく、単一のデータベースと優れたバックアップ戦略で解決できる可能性があります。
負荷分散Webアプリケーションの従来の見方は、RESTサービスを複数のアプリケーションサーバーに配置し、単一のデータベースサーバーからリソースデータを取得するというものだと思います。
ただし、ハイパーメディアを使用すると、RESTサービスはアプリケーションを簡単に垂直に分割できるため、一部のリソースはあるサービスから、一部は別のサーバー上の別のサービスから取得されます。これにより、単一のデータストアがなくても、ドメインに応じてある程度拡張できます。明らかに、RESTを使用すると、これらのサービス間でトランザクションの更新を行うことはできませんが、このパーティショニングが役立つシナリオは確かにあります。
実際に拡張する必要のあるアーキテクチャを検討している場合は、分散キャッシュの問題に取り組む前に、CQSアーキテクチャ（ビデオ）に関するGregYoungの記事を検討することをお勧めします。