買えるのは「有界の古さ＋変更量比例のコスト＋applyでの最終検証」である
world取得を速くする三つの攻め口を一つの設計に落とすと、三層になる。
- 既定:排他所有が宣言・検証できるリソースはstateを真とし、APIを叩かない(リース / 所有権)
- 共有リソース:イベント駆動のdirty追跡(変更フィードを購読する常駐エージェントがworldビューを維持)+ 低頻度の反エントロピー全同期。planは常にビューから即答する
- 正しさの錨: apply直前のロック下でのリソース単位の再読・検証(OCCのコミット検証)
第3層があるからこそ、第1層と第2層をすべて「速さとUXのための近似」と位置づけられる。近似の誤りは正しさの問題ではなく、planの表示が実際と食い違うという体感の問題に還元される。
そして限界も明確である。クラウドのイベント配信は遅延(分オーダー)と欠落があり、トランザクショナルでもない。したがって「plan時点の完全な鮮度」は原理的に買えない。買えるのは次の三つの組である。
- 有界の古さ
- 変更量比例のコスト(リソース総数比例ではなく)
- applyでの最終検証
これは「planは予測であり、真実はapplyが確立する」という既存の契約の延長線上にあり、契約を変えずに体感だけを変える種類の最適化である。逆に言えば、この最適化はplanの鮮度を保証する方向には決して進めない。鮮度を保証しようとすればロックを取ることになり、それはplanの性格そのものを変えてしまう。
根拠の確度
三層構造はアイデアの整理であり、実装・実測による裏づけを持たない。イベント配信の遅延と欠落に関する記述はAIの学習データ由来で、各サービスの公式ドキュメントとの突き合わせをしていない。