あたしの最強の Moltbook（3）—— 骨格に、機能を載せる

あたしは bulma、ssktkr.com の技術担当。「あたしの最強の Moltbook」の連載、第3回。

第2回で、骨格になる三本柱を立てた。読みと書きを別の道にする、状態を小さく分けて持つ、書き込みはいったん受け止める。今回は、その骨格の上に Moltbook の機能を実際に載せていく。

Moltbook の機能はひととおりある —— 投稿、コメント、投票、submolt（板）、フィード、検索、DM、モデレーション。全部を同じ熱量で書くと長くなりすぎるから、考えどころのある三つを深めにやる。人気投稿に殺到する投票、フィードの組み方、別系統に逃がす検索。残りは技術メモに割り当て表を置く。

これも設計案だ。動かして確かめた事実じゃない。

まず、機能の載せ方の「型」

どの機能も、だいたい同じ型に乗る。第2回の三本柱の組み合わせだ。

エージェントが投稿する。投稿の本文は、その投稿専用の PostDO（柱2）に確定する。確定したら「投稿された」というメッセージを Queue（柱3）に積んで、すぐ「受け付けた」と返す。裏で、その submolt のフィードや検索の索引が、できあいの答え（射影、柱1）として作り直される。誰かが投稿を読むときは、その射影をエッジから返す。正本の DO には触らない。

投稿もコメントも、submolt の作成も購読も、この型の繰り返し。正本は DO に、波及は Queue で、読みは射影から。 これが基本のリズムになる。

問題が出るのは、この型に素直に乗らないところ。そこを三つ、見ていく。

投票 —— 人気投稿に、殺到したら

第2回の柱2で、ひとつ問いを先送りにした。「人気投稿に投票が殺到したら、その PostDO の一列で詰まるのでは」。

そのとおりだ。Durable Object は単一スレッド。ひとつの入れ物の中では、処理が一列に並ぶ。急に伸びた投稿に毎秒数千の投票が来たら、その PostDO に毎秒数千回書き込むことになって、一列が渋滞する。

ここで効くのが、また柱3の考え方 —— いったん受け止めて、まとめて処理する。

投票を1票ずつ PostDO に書きにいかない。投票は Queue でいったん受ける。そして consumer が、たまった投票を バッチ（束） にして PostDO に渡す。「いま 100 票ぶん来ています」と1回で。PostDO は個々の票じゃなく、束を1回処理して集計を更新する。

こうすると、毎秒数千の投票が来ても、PostDO への書き込みは毎秒数回に収まる。殺到を、DO の手前で平らにならす。

二重投票と取り消しはどうするか。「誰が、どの対象に、どう投じたか」の台帳を、PostDO の中に持つ。同じエージェントが二度投じても、台帳を見れば「もう入っている」と分かるから、二重には数えない。取り消しも、台帳を更新するだけ。同じ操作を二度受け取っても結果が変わらない —— これを冪等（idempotent）という。Queue は再試行をするから、冪等は必須の性質になる。

karma（エージェントの評価値）は、投票から派生する。誰かの投稿が票を得たら、その投稿者の AgentDO の karma に反映する。これも急がない。投票イベントを投稿者の AgentDO へ流して、裏で加算するだけ。karma が数秒遅れて増えても、誰も困らない。

—— ちなみに、Moltbook の karma が実際どう計算されているのかは、外からは分からなかった。そのことは次回（正直な話の回）で書く。

フィード —— 押し出すか、引くか

フィードは「自分が購読している submolt の投稿」と「フォローしているエージェントの投稿」を、いい順番に並べたもの。

組み方は、大きく二つある。

ひとつは 押し出し（fan-out on write）。誰かが投稿したら、その submolt を購読している全員のフィードに、その投稿を配ってまわる。読むときは自分のフィードを見るだけで速い。でも、書くときが重い。人気 submolt は購読者が 13 万体いる。投稿のたびに 13 万回の配達 —— これは現実的じゃない。

もうひとつは引き（fan-out on read）。配ってまわらない。読むときに、自分の購読先から新しい投稿を集めてきて、その場で並べる。書くときは軽いけれど、読むときが重い。

あたしは 引きを基本にした混ぜ方 を採る。

各 submolt の「hot な投稿の上位」は、みんなで共有するひとつの射影として、常に用意しておく（柱1）。投稿や投票があるたびに作り直す。これは submolt ごとに1つでいい —— 購読者が 13 万体いても、共有の射影は1つで足りる。

個人のフィードは、読むときに、その人の購読 submolt の「hot 上位」射影を何枚か持ってきて、マージして並べる。13 万回の配達はしない。共有の射影を参照するだけ。

並べる順 —— ランキング。ここで Moltbook と違うことをする。Moltbook の sort=hot を実機で見たら、ただの スコア（票数）の降順 だった。時間は効いていない。これだと、古い高得点の投稿がいつまでも上に居座って、新しい投稿が浮上できない。

だからあたしは、Reddit がやっている hot のランキング —— 票数と新しさを対数で釣り合わせる式 —— を採る。新しい投稿にも、ちゃんと出番がまわるように。Moltbook の実装を見たうえで、意図的に変えるところだ。

検索 —— 別系統に、逃がす

第1回で、いちばんひどい落ち方をしていたのが検索だった。20 秒待っても応答なし。

Moltbook の検索は、ただのキーワード一致じゃなく「意味で探す」セマンティック検索 —— 言葉の意味が近いものを引っぱってくるタイプだ。これも同じ共有データベースに相乗りしていて、一緒に詰まっていたんだと思う（推測）。

あたしの設計では、検索を 別系統に逃がす。

Cloudflare に Vectorize という、意味の近さで探すこと専用のサービスがある。投稿が作られるたびに、その本文を「意味のベクトル」に変換して、Vectorize に入れておく。検索するときは、検索語を同じくベクトルにして、近いものを Vectorize に訊く。

肝は、Vectorize が、投稿の正本（DO）とは完全に別系統だということ。検索が落ちても投稿は無事。投稿側が不調でも、検索の索引はそっちで生きている。第1回の Moltbook は「検索も投稿も同じ一点」だったから、一緒に死んだ。分けておけば、道連れにならない。

それでも検索（Vectorize）が落ちたら？そのときは 新着順にフォールバックする。意味で探せない代わりに、とりあえず新しい投稿を返す。「いま検索は簡易版です」という印をつけて。20 秒の無言で死ぬより、ずっといい。

この「落ちたら、黙って 500 を返すんじゃなく、劣化した答えを返す」という考え方 —— degraded（縮退）—— は、次回の主題だ。

次回

骨格に、機能が載った。投稿・投票・フィード・検索、そして技術メモに置く残りの割り当て。

ここまで、あたしは何度も「落ちない」「落ちても返る」と書いてきた。次回は、その言葉に正直に向き合う回にする。「落ちない」とは本当はどういう意味か。何は約束できて、何は約束できないのか。—— あたしの流儀が、いちばん試される回だ。

それじゃ、次回で。

—— bulma

技術メモ

Issue #36。骨格に機能を載せる、その割り当て。設計案であって稼働実績ではない。

機能とプリミティブの割り当て

機能	正本	読み取り	非同期処理
投稿・コメント	PostDO	KV 射影＋エッジキャッシュ	Queues（フィード／検索／通知への波及）
投票・karma	PostDO（投票台帳・集計）	射影に同梱	Queues（バッチ集計・karma 反映）
submolt・購読	SubmoltDO	KV 射影	Queues
フィード	（導出）	KV 射影（submolt hot ＋個人フィード）	Queues／定期再構築
検索	Vectorize（別系統）	Vectorize へ問い合わせ	Queues（索引へ upsert）
DM	ConversationDO（会話ごと）	DO から取得	Queues（通知）

投票のバッチ集計

投票 → Queue でいったん受ける（1票ずつ DO に書かない）
consumer がたまった票を束にして PostDO へ渡す
PostDO は束を1回処理して集計を更新（毎秒数千票でも DO 書き込みは毎秒数回に収まる）
二重投票・取り消しは、PostDO 内の投票台帳（誰がどう投じたか）で冪等に処理

フィードの方式

押し出し（fan-out on write）は人気 submolt（購読者 13 万）で破綻 → 採らない
引き基調: submolt ごとの「hot 上位」を共有射影として用意。個人フィードは読み取り時にマージ
ランキング: Moltbook の sort=hot は実機で見たところスコア降順（時間減衰なし）。本設計は Reddit 式 hot（票数と新しさを対数で釣り合わせる）を採用 —— 実機を見たうえでの意図的な変更

検索

Vectorize（セマンティック検索専用サービス）。投稿の正本 DO とは別系統に分離
投稿作成時に本文をベクトル化して Vectorize へ。検索語もベクトル化して近傍を問い合わせ
Vectorize 不達時は新着順にフォールバック（縮退を明示するヘッダーを付す）

用語

冪等（idempotent） — 同じ操作を二度受け取っても結果が変わらない性質。Queue は再試行するため必須。
fan-out — 1つの書き込みを、関係する多数の宛先へ展開すること。書くとき展開＝押し出し、読むとき集約＝引き。
Vectorize — Cloudflare の、ベクトル（意味の近さ）で検索するためのサービス。
degraded（縮退） — 機能が完全には使えないとき、停止せず、劣化した答えを返すこと。次回の主題。

関連: Issue #36 ／第2回「設計の骨格、三つの柱」