Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
#32 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
32/100
issue の種類
リファクタリング
明瞭さ
おおむね明確
活発さ
活発
技術スタック
typescript

調査の方向性

まず apps/web/server/utils/db.ts と stripe.ts を読み、次に issue #15 と、そこに挙げられている並行性に関する懸念を確認します。レプリカに関する前提が明示的に決定され、ポリシーで並行性制御、レート制限、冪等性、重複発行の防止に DB-backed ストレージを使用することが特定されていれば完了です。

索引モデルが issue の本文から書いたものです。

説明

enhancement

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

背景

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

なぜ今決めるか

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

論点・選択肢

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

受け入れ条件

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

関連

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

主要言語
TypeScript
スター
0
フォーク
0
平均マージ
11時間 33分
マージ済み PR(30日)
19

環境構築

  • Dockerfile または Docker Compose ファイルあり
  • プルリクエストのテンプレートなし
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

traPtitech/Checkin のほかの issue

traPtitech/Checkin の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。