面接振り返り:在庫・トランザクション(9/17〜9/21)
2026-09-17 00:21 EDT開始、9/19・9/21に再開。元のsession dateは開始日。対象はdatabase-transactions、シナリオは「残り1個の商品を2人が同時購入」。指定シナリオID・質問カードID・資料参照申告はunknown。既存のトピック入口から始まった単一topicの記録で、原稿に従う横断テストの実施とは扱わない。
正本:session YAML・Issue #24。下記のQ1〜Q5は読みやすくするための本ページ内整理番号で、事前に存在した質問カードIDではない。各回答の正確な日付はunknown。
面接としてどうだったか
Section titled “面接としてどうだったか”最初の独力回答で、在庫更新と購入記録を同じtransactionへ入れる境界は示せた。一方、同時に同じ在庫を読む条件では競合制御を具体化できず、FOR UPDATEの解法説明へ移った。以後は説明と確認の混在なので、最終的に話せた内容を初回独力の能力へ遡らせない。
その中でAtomicity、通常SELECTの可視性、writerの待機、再試行の負の連鎖は自分の言葉で説明した。大きな再確認点は「transactionの境界」と「同時実行の保証」の違い、および待機・再試行・複数行不変条件から方式を選ぶ理由。数値スコアや肩書の合否には換算しない。
回答と判断の変化
Section titled “回答と判断の変化”| 問い・条件 | 回答と支援の順序 | 今回の根拠 |
|---|---|---|
| Q1 残り1個を2人が購入。どこをtransactionにするか | 初案は独力で「購入レコードとその在庫の状態みたいなのを更新する処理をトランザクションに」。双方stock=1を読める条件追加後は「わからない」。その後FOR UPDATEを解法説明 | 境界は提示できたが、初案で競合制御は具体化できなかった |
| Q2 1000人が最後の1個を購入、pool=50 | 「どうせ一人しかアクセスできないので性能上の問題が分からない」。lock waitとpool占有を説明後、「50個全部使う」「これはつらい」。条件付きUPDATEのSQLを提示後、「アップデート一つで済む」 | 人数とpoolは演習条件。待機の波及・条件付きUPDATEは説明後の理解 |
| Q3 在庫UPDATE後に購入INSERT失敗、Aが更新中にBが読む/書く | 同じtransactionならrollbackすると説明。AのFOR UPDATE中のB UPDATEは「待たされる」、通常SELECTはcommit済みの1、RCでA commit後の再読は0と回答 | これらの問いでは解法ヒントなしと記録。ただしセッション前半でロック説明は受けている |
| Q4 RR/Serializable、NOWAIT/SKIP LOCKED、version | RRは「なんだそれ」、NOWAITは「聞いたことない」。基本挙動を説明。version付きSQL提示後に不一致なら0行と回答。Serializableのretryには「いらないんじゃね」と考えたためabortと再試行を説明 | 未学習・未整理からの再学習。FOR UPDATE即失敗とした説明はNOWAITと区別して訂正 |
| Q5 当直2人、最低1人ON、高競合 | write skewの仕組みを説明。共通1行へ競合を寄せる観点ヒント後「当直の人数っていうのをレコードに」。比較は「トレードオフまでは…思いつかない」。retry連鎖は「負の連鎖が入りそう」と回答 | 共有カウンタ案はヒント後。retry増加の悪循環は高競合の影響を問われて自分で説明 |
外部決済では冪等性・状態照会の案も出たが、本人の希望でDBへ戻った。外部APIの設計全体や実務適用を評価済みにしない。deadlockは次へ進みかけたところで終了希望があり、未出題。忘却や不足に分類しない。
同期時の技術補足:「楽観ロックなら待たない」は一般に成立せず、version付きUPDATEも行ロックを待ち得る。不一致で0行という理解と、待機の一般化を分けた。通常SELECTもtable lockは取る。これらは教材へ補い、本人の再確認が済んだとはしない。
役割の観点からの評価
Section titled “役割の観点からの評価”| 観点 | 回答で示せた判断 | 不足・支援が必要だった点 | 未確認 |
|---|---|---|---|
| シニアBackend | Q1の境界、Q3の失敗時rollback・通常read/writeの差 | Q1の競合制御、Q4の分離レベル別の失敗・retry | DBでの実装・実測、deadlockの対応 |
| Tech Lead | Q5でretryが競合を増やす危険を認識 | Q2/Q5の待機・再試行・hot row・実装単純性の比較 | チームでの合意形成、移行・運用での実践 |
| Architect | Q2のpoolへの波及、Q5の複数行不変条件を説明後に整理 | 行ロックだけで足りる境界と、別行の依存を扱う手法選択 | 分散構成全体・サービス境界を横断した判断 |
不足と次に確かめること
Section titled “不足と次に確かめること”| 分類・根拠 | 設計への影響 | 学び直しと再確認 |
|---|---|---|
| 競合制御の具体化不足:Q1「わからない」 | Atomicityだけで二重販売を防げると誤認し得る | transaction/条件付きUPDATE/行ロックを同じ在庫例で説明。購入INSERT失敗時まで追う |
| 挙動の誤り・未整理:Q4通常FOR UPDATEを即失敗、RR/NOWAITを未認知 | 待ち時間・エラー処理・retry単位を誤り得る | RC/RR/SerializableとNOWAIT/SKIP LOCKED、version競合を別条件で予測 |
| trade-offの理由不足:Q5「思いつかない」 | 正しさは保てても過負荷やhot rowへ待ちを移す可能性 | 共有カウンタとSerializable、短い条件付きUPDATEを比較。待機/abort/retry/poolを測る |
既習の忘却か未学習かは発言以上に推定しない。関連教材は在庫・ロック・分離レベル。再学習直後の答え直しと、別日の独力再確認を区別して履歴へ追加する。
不足を補う学習を始める
Section titled “不足を補う学習を始める”学習1:同じ行の在庫と競合
Section titled “学習1:同じ行の在庫と競合”カバーする不足はQ1・Q4のtransaction境界と競合制御、分離レベル・待機・retryの区別です。
https://github.com/MFQWKMR4/tech2026 のCHATGPT.md、AGENTS.mdと次を読んでください。- sessions/2026-09-17-database-transactions-01.yaml- src/content/docs/practice/reflections/2026-09-17-database-transactions-01.md- reviews/database-transactions.yaml- src/content/docs/database/transactions.mdx- public/diagrams/database-transactions/isolation.svgsession_type: learn、topic: database-transactionsです。元テストQ1は境界の初案は出たが競合制御は説明が必要、Q4は待機・RR・retryが未整理でした。最初に私の現在の説明を聞き、必要なところから一つずつ説明・具体例で学び直してください。同じ在庫のA/BをRC/RR/Serializableで追い、Aがcommit/rollbackするとBに何が見え、更新・待機・失敗はどうなるか確認してください。楽観ロックもUPDATE時に待つケースと、commit済みversion不一致の0件を区別してください。初回独力と説明後を分け、答え直しだけで定着済みにしないでください。終了時は既存YAML+Session narrativeの[Session Sync]をMFQWKMR4/tech2026へ作成しURLを返してください。summaryに元テスト2026-09-17-database-transactions-01、対象の不足、今回の回答・支援・残った課題を残してください。作成できなければ未作成と明示してコピー可能な本文を返してください。学習2:複数行の不変条件と高競合
Section titled “学習2:複数行の不変条件と高競合”カバーする不足はQ2・Q5のpoolへの波及と、共有カウンタ/Serializableのtrade-offです。
https://github.com/MFQWKMR4/tech2026 のCHATGPT.md、AGENTS.mdと次を読んでください。- sessions/2026-09-17-database-transactions-01.yaml- src/content/docs/practice/reflections/2026-09-17-database-transactions-01.md- reviews/database-transactions.yaml- src/content/docs/database/transactions.mdx- public/diagrams/database-transactions/write-skew.svgsession_type: learn、topic: database-transactionsです。Q5では共有1行への観点ヒント後にカウンタ案を出しましたが、trade-offは説明できませんでした。現在の説明を聞き、write skew、共有カウンタ、Serializable+retryを一つずつ学び直してください。設計への影響として、hot row・lock wait・abort/retry・pool占有を比較してください。最後に別の複数行不変条件で、選ぶ方式と代償を一問ずつ確認してください。未提示条件はunknown、追加条件は演習と明示し、初回独力とヒント後を分けてください。終了時は既存YAML+Session narrativeの[Session Sync]をMFQWKMR4/tech2026へ作成しURLを返してください。summaryに元テスト2026-09-17-database-transactions-01、対象の不足、今回の回答・支援・残った課題を残してください。作成できなければ未作成と明示してコピー可能な本文を返してください。