クライアントサイドにセッション情報を記録するとシステムのスケールの仕方が変わる？

最近、ふと思いました。
adobe airやsilberlightのようなものが使われてクライアントサイドが
リッチになると、システムのスケールの仕方に幅が出る様な気がします。
特に気になってるのは、SLBを使ってスケールアウトするときです。

まぁ独り言ですが。

1. セッションの持ち方

サーバアプリが処理途中のデータなどを保存する場合、通常は「セッション」を利用します。
ブラウザから通信をする場合、ブラウザ側はCookieしか持てないので
従来のSLBはセッションのIDだけをCookieに格納して、セッションのデータ本体は
サーバ側に置くという作りが普通でした。

airやsilberlightを使えば、このセッション情報も
クライアントサイドに格納できるようになる、と思ってます。

2. SLBの動作の変化

まず基本です。

同じ機能を持つWebサーバを複数台並べてスケールさせるときに、
各サーバ上に記録されるセッション情報にアクセスさせるには
「同じセッションのリクエストをすべて同じサーバに振り分ける」
という振分要件が出てきます。
これはSLBの振り分けだと「sticky session」と呼ばれる機能です。

このセッション情報がクライアントサイドに格納できるようになると、
常に同じサーバに振り分ける必要がなくなるのではないかと。

たとえば、買い物かごの例を考えると、ざっくり以下の3パターンになります。
１．買い物かごの処理を開始するときにセッションを生成する。
２．買い物かごに商品を入れるたびに、セッションの格納場所に商品IDを覚えさせる。
３．購入ボタンを押したら、買い物かごのデータをDBに格納する。

クライアントサイドにセッション情報を持つ場合は、１および２は
クライアント側に覚えさせるので、リクエストが
どのサーバに行っても問題ありません。
３の処理のタイミングで、買い物かごのデータすべてを読みだしてDBに転送
するようにすれば、SLBにはsticky sessionの機能が
なくても良いということになりそうです。（３の処理は重くなるかもしれませんが）

つまり、クライアントサイドにセッション情報を格納すれば、ラウンドロビン等の
単純なアルゴリズムで振り分けていればよくなりそうです。

3. 懸念事項・課題

ぱっと思いつく懸念は、セキュリティでしょうか。
クライアント側から３の処理で買いものかごのデータをすべて
DBに格納するとき、を装って
悪意のある人が異常データを送り込めるような気がします。

従来技術ではログインしたかどうかをサーバ側のセッションとして保存して、
ログイン済みなら処理OKというような作りになると思います。
セッションの情報すべてをクライアント側に残すと、
クライアントをすべて信用することになるので
DB格納時のタイミングで権限チェックをする機構が必要そうです。

4. その他

他にもあるかもしれませんが、眠くなってきたのでこの辺でやめときます。
またググってないので、既に誰かが書いてるような気もしますが
まずは気にせず書いてみました。