いろいろ考えているのだけれど、どう考えてもキャッシュ層は必要だと思います。今のシステムにそれがないとは言わなけれど、もっと頑健で、単一故障なんて全く問題にならないようなキャッシュ層が必要だと思います。ちなみに、ここでのキャッシュ層は、別にフロントエンドからのリクエストを単に溜めておくようなキャッシュ層ではなく、一部のバックエンド側のデータをメモリ DB 的何かに蓄えておくようなイメージをしています。
正直なところ、スキーマレスとかはどうでも良いのですが、だからといって RDB に拘泥するつもりもありません。データ参照に局所性があるシステムなので、コスト対効果的にシャーディングも要らないような気もします。やっぱり悩むのはバックエンドとキャッシュとの同期で、それを考えるには更新をどっちの層に最初に実施するのかという決めが必要になるのかなと。
- キャッシュ層に対して更新を行い、その更新をバックエンドに伝搬させる
- バックエンドに対して更新を行い、キャッシュ層にその情報を伝搬させる
- バックエンドに対して更新を行った際、キャッシュ側のデータは invalidate する
- バックエンドに対して更新を行っても、キャッシュ側で expire されるまでデータ不整合を許容する
どの方針を選ぶのかは、当然ながら何をキャッシュ側に持たせておくのかに依存するところ。金が絡むところなどはデータ不整合なんて許容できないでしょうが、数量としてざっくりで良いようなデータは、別に多少の不整合があっても許容されます、たぶん。とはいえ、不整合が許容できるデータと許容できないデータを同じ層の同じ仕組みの上に載せるのは、システムも運用もあまりに複雑になりそうなので避けたい。
それを考えると、やっぱし何を載せますかというところで複数プランを用意すべきか。
