100万ユーザーが1000個のコードを奪い合う際に、オーバーセル（在庫超過販売）をどう防ぎますか？

Question

IT Interview Practice · Accepted Answer

在庫カウンターを**単一のアトミックな場所**に保持し、アトミックにデクリメントします。残数を返すRedisの `DECR`（またはLuaスクリプト）を使います。結果が `< 0` なら、そのリクエストは負けです。データベースは*決して*並行性のゲートにしてはいけません。残りは、他の999,000リクエストをいかに安価に切り捨てるかの話です。 ## アーキテクチャ ```text 1M clients ─▶ CDN/edge (waiting room, drop bots) ─▶ LB │ Stateless API pods │ Redis: DECR stock (Lua: check+dec+record) │hit>=0 │miss<0 ▼ ▼ enqueue order ─▶ DB reject "sold out" ``` ## コンポーネントと処理の流れ - **待機室 / アドミッションコントロール**をエッジに置くのが第一の防御です。100万接続をAPIに到達させず、キューページ（Cloudflare Waiting Room方式）が制御されたバッチでユーザーを入場させます。これによりスパイクをストリームに変えます。 - **Redisのアトミックデクリメント**が在庫の唯一の真実の源です。`DECR stock:sale123` はアトミックで、2つのリクエストが両方とも「残り1」を読むことはありません。**Luaスクリプト**は1往復でこれを行います。残数を確認し、デクリメントし、`SADD winners:{sale} {user}` で記録して1人のユーザーが二度勝てないようにします。LuaはRedis上でシングルスレッドで動くため、check-and-set全体が1つのアトミックなステップです。 - **注文キュー → DB**：勝者（結果が `>= 0`）はキューにpushされ、workerが非同期でPostgresに注文を書き込みます。DBが100万件の同時書き込みを受けることはなく、約1000件の勝者書き込みのみです。 - **却下パス**は敗者に即座に「sold out」を返します。高速な却下は機能です。接続を解放し、バックエンドを保護します。 ## 面接での観点面接官は、あなたが**レースコンディション**を正確に言語化できるかを見たいのです。2文に分かれた `SELECT stock` の後の `UPDATE` は、2つのリクエストが両方とも1000を読み、両方とも販売してしまう典型的なオーバーセルです。「良い」回答は「トランザクション / `SELECT ... FOR UPDATE` を使う」ですが、「優れた」回答は、行ロックが100万リクエストを1つのホット行に直列化してスループットを崩壊させると認識し、競合をRedisのシングルスレッドのアトミック操作に移し、勝者のみを永続化することです。罠は、アトミック性のないアプリケーションレベルのチェック（`if (stock > 0)`）を信頼することです。 ## トレードオフと障害 - **Redis対DBの `FOR UPDATE`**：Redisは1つのホットキーで10万以上のops/sを処理します。Postgresの行ロックは直列化し、フラッシュセールで溶けます。DBは永続的な注文レコードに専念させます。 - **可用性対正しさ**：セール中にRedisが故障したら、**fail closed**（却下）が必須です。セールを再開すればオーバーセルのリスクがあります。販売済み数を永続化し、真の残数を復旧できるようにします。 - **一貫性**：セール後にRedisの勝者とDBの注文を照合します。DB書き込みが失敗した勝者には、枠を返金するか再付与します。ユーザーごとのrate limitとボット検知を追加しないと、スクリプトがミリ秒で在庫を枯渇させます。

アーキテクチャ

コンポーネントと処理の流れ

面接での観点

トレードオフと障害

関連する質問