これ、考えてみよう

webサービスやる人にとっては永遠の問題だわねー。以下、戯言。
Railsはモックアップ作って、何が問題・ボトルネックかを把握するためのすばらしい舞台だということだな。別にボトルネックが無いなら、そのまま運用すればいいし。
スケールアウトできる設計をしとけば、大抵はRailsのままでいけるはずだ。スケールアウトできない部分を、現行のRailsのシステムを崩壊させない形で取り出せるか、が、ケーススタディではキモのように感じる。
スケールアウトできるようにするには、整合性が常に問題になる。
・更新の局所性（ユーザのカテゴライズでも良い）を維持できるか。もしくは更新の局所性は無くても、整合性が永続的に破壊されなければＯＫというルールを適用できるか。
スケールアウトじゃなくてスケールアップしようとして取るのが、キャッシュを入れようとか、処理の重い部分をtuningしよう、という話だが、tuningのネタが無限にあるわけじゃないので、このテは数回きりだと諦めるべきだろう。ビジネスの限界が技術者のレベルで規定されてしまう。
いずれにしても、設計というかシステムのアーキテクチャを仔細に見なければ「何をすべきか」は何もいえない。その前提となる「おもてなしの方針」はしっかりしてるみたいなので、そこから導きだされた設計についてはあまり心配要らないような気がするけど。
さて、えらそうな法螺吹くのはこの程度にして、自分の頭のハエを追うことに戻ろう。

(2008/9/25追記)元記事のほうにフォローがあったようだ。そしてそれを読んで考えたこと。

要するにgracefullに壊れたいということなのかな。ならば、壊すテスト環境を先に作っておいたほうがいいな。gracefullに壊れつつある状態と、連鎖反応でどうにもならなくなる状態の境界を探るテストをしておくべきだろうな。どこぞのコメントにもあったけど、まずは謝れるうちに「ごめんなさい」と素直に謝るポイントをしっかり把握しておくべきだと思う。そして、それを現行のシステムに適用してみて、まずは「ごめんなさいUI」を作りこんでおく、と。
もしくは、「僕、病弱なんですUI」とかね。だんだんとページが軽くなって、青ざめた感じになっていく、とか、非同期通信のラグが大きくなると、手元の端末で赤ランプぴこぴこし始めるとか。例えば「アンテナ１本になっちゃう」というのはすばらしいインターフェースだと思う。