デプロイ・トポロジ(単一/複数レプリカ)を確定し、並行制御の状態を DB に寄せる

前提の格上げ(#39): デプロイ・運用先(基盤)自体が未確定と整理した。論点を「まず運用先を決める。トポロジはその下流」に引き上げる。運用先が決まるまでは単一レプリカ前提とし、共有状態を DB に寄せる(プロセス内シングルトンをやめる)方針は運用先非依存に今確定する。

背景

apps/web/server/utils/db.ts / stripe.ts は「サーバーインスタンスごとに 1 つ生成しキャッシュ」= プロセス内シングルトン前提で、単一レプリカか複数レプリカかという前提が暗黙に埋まっている。

なぜ今決めるか

複数レプリカに移ると、インメモリ状態に依存した機構が一斉に壊れる — レート制限(#15、インメモリでは効かず共有ストアが要る)、ジョブの多重実行、二重発行防止、冪等ガード。これらの実装形はレプリカ前提に規定されるため、実装する前に前提を確定する方が安い。後から全部 DB 化するのは高い。

論点・選択肢

• 単一レプリカで進める(シンプル)か、最初から複数レプリカ耐性(共有すべき状態は DB/外部ストアのみ)を前提にするか。
• 前提が決まると: #15 のレート制限ストア、非同期基盤のリーダー選出要否、突合ジョブの排他制御、二重発行防止(ドメインモデルの (member, term) 制約)が決まる。
• NeoShowcase の運用実態(レプリカ数・スケール方針)は情報不足なら当面「単一レプリカ前提、共有すべき状態は DB に置く」と宣言しておくと後続が安定する。

受け入れ条件

• レプリカ前提が宣言され、並行制御・レート制限・冪等・二重発行防止の状態を置く場所(プロセス内不可、DB へ)の方針が決まっている。

関連

#15(レート制限)の実装形を左右する。お金の記録・非同期基盤・ドメインモデルの並行制御と接続する横断前提。

Start by reading apps/web/server/utils/db.ts and stripe.ts, then review issue #15 and the listed concurrency concerns. Done means the replica assumption is explicitly decided and the policy identifies DB-backed storage for concurrency control, rate limiting, idempotency, and duplicate issuance prevention.