冪等性・連打耐性デモ

1. 発注フォーム

安全な実装（既定・DB UNIQUE制約）安全でない実装（比較用・naive）

Idempotency-Keyは「商品名・金額・モード」が変わらない限り同じUUID v4を使い回します（Stripe等の実際の決済APIと同じ発行方針）。この状態のまま連打・多重クリックすると「同一操作の再送」として扱われ、安全な実装なら何度押してもDB件数は1のままです。商品名や金額を変えると新しい発注として新規キーが発行されます。

2. 🔥 連打を自動再現（決定論的リクエストラッシュ）

同一のIdempotency-Keyで、設定された件数のリクエストをPromise.allにより同時発火します。

3. 検証パネル

対象Idempotency-Key

このアプリでできること

「発注確定」のような、一度きりであるべき操作ボタンをうっかり連打したり、通信の遅れで二重に送信してしまったりしても、データベースには1件しか登録されないようにする仕組みを、実際に動かして確認できるデモです。
「安全でない実装」と「安全な実装」を切り替えて比較でき、対策の有無で結果がどう変わるかを目で見て確認できます。
多数のリクエストを完全に同時発火するボタンもあり、通信のタイミングが重なった場合でも壊れないことを確認できます。

使い方

「安全でない実装（比較用）」を選び、「🧪 クライアント側の連打防止を無効化」にチェックを入れてから、発注フォームを連打するか「🔥 連打を自動再現」ボタンを押してください。検証パネルでデータベースに複数件登録されてしまう様子を確認できます。
「安全な実装（既定）」に戻し、同じ操作を繰り返してください。何度連打・自動再現しても、データベースの件数は常に1件のままであることを確認できます。
検証パネルの「DB件数を数える」「全行一覧を取得」「直近ログを取得」ボタンで、実際のデータを直接確認できます。

注意点・既知の制限

これは実運用システムそのものではなく、「一度きりであるべき操作の多重実行事故を防ぐ設計」を体験・実演するためのデモです。
通信をわざと遅らせるような仕掛けは使わず、実際の通信タイミングのばらつきだけで同時アクセスの状況を再現しています。
サーバーの処理がデータベースへの書き込み途中で強制終了した場合の挙動までは、自動確認の対象に含まれていません。
画面上部の案内文言は暫定のものです。