2026-09-10 面接振り返り：イベント開始時の集中アクセス
2026-09-10、**INT-BURST-01 v1（2026-09-09）**の口頭interview。Q1から派生した障害条件を扱い、Q2容量・SQSのQ3・DB占有・Q4大量復旧は未出題。
- 正本：session YAML／Issue #13・会話の流れ
- 対象：architecture-scaling、architecture-queues、architecture-api-idempotency
- 元の学習：スケール・キュー・API冪等性（各2026-09-08のsession）
- 参照revisionの申告：
a4d00402d419f67f9a917dc1ff6ed73aebb679aa。直前・途中の教材参照申告はunknown。日付差は2日だが、それだけで資料なしの定着を認定しない。
以下のR1〜R7は今回の実際の進行を辿るための区分で、原稿Q2〜Q4の実施を意味しない。条件は演習であり、本人の実務経験・実測ではない。
面接としてどうだったか
Section titled “面接としてどうだったか”初回に、受付APIの水平分散、queueによる受付と処理の分離、外部能力に合わせたconsumer rate、受付と完了の区別を説明できた。続く障害条件では、DBに残った未投入仕事の再送、同じ業務IDの重複投入許容、DB一意制約による競合制御、providerの冪等性契約を使う方向まで提案した。
大きな課題は二つ。受付直後の状態を何から確かめるかは、追質問と観点ヒントを受けてDB導入へ変更した。外部成功と自DB記録を一体にできない境界は、冪等性を持たない外部serviceという条件で自力では解決案を出せなかった。説明後のat-most-once選択は、初回独力の証拠にはしない。
queueのみの受付が必ず非durableという評価ではない。今回確認できたのは、consumerがDBへ記録する前に状態取得APIが受付済みを判別できない問題である。queueの耐久性・検索機能の実契約は未確認。
回答と判断の変化
Section titled “回答と判断の変化”R1：初回独力の設計
Section titled “R1：初回独力の設計”開始問題は「イベント開始時に受付が集中し、受付後に外部サービスを使って処理するシステム」の設計。利用者へ受付結果と進み具合を伝える。
初回独力・ヒントなし：API serverを水平スケール可能にし、queueでproducer/consumerを分離する。「外部のAPIサーバーが処理できるスピードでキューから取り出していく」と説明し、queue容量設計の必要性も挙げた。進捗は、queue投入時に受付成功、consumer開始後にDBへprocessing、完了後にcompletedを保存して状態取得APIで見せる案。受付時は「DB書込みを発生させたくない」とした。
原稿の数値・SLO・DBへ保存できる条件を実際に全て開示した証拠はない。その基本条件を初回回答へ遡って適用しない。
R2：追質問、原稿外条件、観点ヒント、条件の見直し
Section titled “R2：追質問、原稿外条件、観点ヒント、条件の見直し”- 中立的追質問：consumer障害も含め、誤解を与えない状態をどこへ持つか確認。本人は受付済みがDBにないと確認できず「これは困りました」とした。
- 演習上の追加条件：面接官が「受付APIはDB書込みなしで、受付完了を即時返す」と提示。本人の初案を原稿外の制約として固定した経緯である。
- 本人はqueueをID検索する案を考えたが、可能か分からないと明言。「正本としてデータベースとキューの2つができてしまう」と問題を認識した。
- 観点ヒント：「状態の正本をどこに置くか」「利用者に見せるのは確定情報だけにするか」を提示。その後「正本はデータベースに置きたい」と回答した。
- 矛盾への追質問：DB正本と受付DBなしをどう両立するか確認。本人は「やはり、データベースを導入しますかね」と受付時DB書込みへ変更した。
これは制約自体を見直した設計変更であり、DBなし条件を満たした解決とは評価しない。protocol deviationとして残し、次回は今回の追加条件を確認した上で条件を明示し直す。
R3：DBとqueueの二重書込み
Section titled “R3：DBとqueueの二重書込み”DBを受付時に使う変更後、DB保存成功→queue投入失敗を提示。本人は受付状態と投入済み状態を分け、未投入を後で再投入し、その後DBを更新する案を出した。
次にqueue投入成功→投入済みDB更新失敗を提示。本人は同じ業務IDの重複投入を許容し、consumerがDBを参照して重複処理を避けると説明した。障害条件の提示後に方式を提案しており、ここでOutbox等の解法名を教えた記録はない。ただしDB導入への変更自体はR2の支援後。
R4：並行consumerとprocessing停止
Section titled “R4：並行consumerとprocessing停止”同じIDを別consumerが受け、両方が未処理と読むraceを提示。本人はattempt IDの一意制約とtransactionで、書込みに成功したconsumerだけが開始権を得る案を出した。
共有キーで競合させる方向は説明できた。一方、attempt IDの生成主体・同じ業務操作で維持する方法・lease世代はunknown。consumerごとに異なるIDを作ってよいという保証にはならず、実装として競合を排除できたとは認定しない。
processingで停止する条件には、一定時間残るrecordを別jobで検出し再実行する復旧案を提案した。経過時間で外部の未実行を証明できるかは、次のR5〜R7で別に扱った。
R5：providerに冪等性がある場合
Section titled “R5：providerに冪等性がある場合”外部成功直後、自DBをcompletedへ更新する前に停止する条件を提示。本人は同じidempotency keyを送る案を自発的に提案し、「この前提が許される場合」とproviderの契約が必要なことも示した。条件提示後の回答であり、keyを教える解法ヒントの記録はない。
2026-09-08の「provider keyが自発的に出なかった」に対する新しい再確認の証拠。今回の回答でその狭いmissingは更新したが、保持期間・scope・状態照会との統合設計まで定着したとはしない。
R6：key非対応の外部課金、独力区間の終了
Section titled “R6：key非対応の外部課金、独力区間の終了”演習上の追加条件として、外部serviceはkey非対応、二重実行がcriticalな課金を提示。本人は「自前で冪等性のある呼び出し」「二回実行されても外部呼び出しはexactly-onceになる仕組み」を考えた。
さらに外部serviceは変更不能、成功後の自DB記録前停止から、自システムだけで成功/失敗をどう判定するかと追質問。本人は考えた後「出せませんでした、ソリューションが」と明言。独力では未解決で、ここでテスト区間を終了した。
providerへの照会不能が最終出題前に明示されたかはunknown。照会不能の扱いはR7の解法説明に記録されている。「絶対に実現できない問題の解法を出せなかった」ことではなく、保証できない境界を説明して要件・契約を見直す判断が独力では出なかったことを課題とする。
R7：解法説明と、その後の回答
Section titled “R7：解法説明と、その後の回答”解法説明：外部成功と自DB記録をatomicにできず、自DBだけから結果を判定できない。照会できればreconciliation、照会もできず二重課金がcriticalなら自動retryを避ける。実行漏れ回避と重複回避を同時に完全保証できない境界を説明した。
説明後：本人は「今回の課金処理は二重実行されることがクリティカルな問題となるので、at-most-onceを選択します」と回答。これは再学習後の理解で、具体的なclaim・retry抑止・UXの実装は未確認。
役割の観点からの評価
Section titled “役割の観点からの評価”| 観点 | 回答で示せた判断 | 不足・支援が必要だったこと | 未確認 |
|---|---|---|---|
| シニアBackend | R1の非同期化、R3の再投入と重複許容、R4のDB競合制御案、R5のprovider契約への条件付け | R2の受付照会契約はヒント後に変更。R6の結果不明境界は独力未解決 | 安定したattempt IDの具体化、実装・実測、SQSの実際の再配送 |
| Tech Lead | R3で重複配送を許容しconsumerへ責務を置く。R4で停止仕事を回収する案 | R6で保証できない場合の実行漏れ・重複のtrade-offが未整理、R7は説明後 | 新規/復旧の優先順位、監視・停止判断、実務のリーダーシップ |
| Architect | R1〜R5でAPI・DB・queue・外部serviceの障害境界を順に扱った | ローカルDBの開始権と外部効果の一回性をR6で独力では切り分けきれなかった | 数値capacity、DB connection占有、redrive全体のcapacity |
肩書の合否や数値スコアではなく、この面接で観測した範囲の評価。3topicのstatusはExplainedを維持する。
不足と次に確かめること
Section titled “不足と次に確かめること”| 区分 | 回答根拠と影響 | 対応する学習・再確認 |
|---|---|---|
| 初期設計の説明不足・支援後に変更 | R1〜R2：受付済みをDB照会で判別できず、利用者に未受付と誤解させる余地 | 受付の耐久性と照会契約。DBへ書ける条件で、受付成功の意味とcommit前後の停止を独力説明 |
| 既習境界の独力再確認で未解決 | R6：「自前exactly-once」を具体化できない。結果不明へのretryで重複、抑止で未実行が残る | 外部結果不明とat-most-once。同じDB状態で外部結果が異なる二例を説明 |
| 設計詳細は未確認 | R4：UNIQUEの方向は提示したがID生成・安定性・lease世代は不明 | 業務IDと処理開始権。新しい欠落実績を作らず、学習時に実装条件を確認 |
| 発展として次に深める | R7は説明後。手動照合・補償・UXの具体的選択は未確認 | 照会契約あり/なしで保留・確認中の表示と運用判断を検討。未学習・未出題を忘却と呼ばない |
Outboxの通信順序ではDBとqueue間の停止位置、保存状態の比較図では同じpending記録からqueueの状態を確定できない点を確認できる。外部副作用の既存図と解説を合わせて、外部の結果不明は別の保証境界として読む。
未出題の続き：容量とSQSをテストする
Section titled “未出題の続き：容量とSQSをテストする”Q2容量、原稿Q3のReceive/Delete/visibility timeout、DB占有、Q4の10万件redriveは今回の不足としない。まずQ2かSQS Q3のどちらか一つを次回独力再確認する。
https://github.com/MFQWKMR4/tech2026 のCHATGPT.md、AGENTS.md、docs/interview/protocol.md、docs/interview/questions.md、docs/interview/scenarios/event-burst.md、sessions/2026-09-10-int-burst-01-01.yaml、reviews/architecture-scaling.yaml、reviews/architecture-queues.yamlを読み、INT-BURST-01のinterviewを再開してください。前回はQ1派生のみで、原稿外の受付DBなし条件と正本への観点ヒントがありました。今回は未実施の原稿Q2かSQS Q3のどちらか一つを選ぶ希望を聞いてください。資料参照の申告と参照できたrevisionを記録し、問題は一問ずつ、答えと評価観点は先に示さないでください。Q2では必要な数値条件を明示し、前回提示済みと仮定しないでください。同じ問いを選ぶ場合は独力再確認の意図を記録し、条件変更・追質問・ヒントを分けてください。終了時は実際の回答を根拠に既存テンプレートのYAML＋Session narrativeで [Session Sync] GitHub IssueをMFQWKMR4/tech2026に作成しURLを返してください。summaryに元テスト2026-09-10-int-burst-01-01との関係と未出題を残してください。作成できない場合は未作成と明示し、コピー可能なタイトルと本文を返してください。不足を補う学習を始める
Section titled “不足を補う学習を始める”A：受付成功とdurableな仕事の記録
Section titled “A：受付成功とdurableな仕事の記録”この学習でカバーする不足：R1〜R2の受付直後の状態照会、R3のDB/queue境界。既存図と説明を使い、一回はこの単位に絞る。
https://github.com/MFQWKMR4/tech2026 のCHATGPT.md、AGENTS.mdと次のファイルを読んでください。- sessions/2026-09-10-int-burst-01-01.yaml- src/content/docs/practice/reflections/2026-09-10-int-burst-01-01.md- reviews/architecture-queues.yaml- src/content/docs/architecture/queues.mdx- diagrams/architecture-queues/outbox.json- public/diagrams/architecture-queues/outbox-snapshots.svgsession_type: learnで、architecture-queuesの不足を補う口頭学習を始めてください。今回カバーする不足：R1は受付DBなし・consumerから状態保存、R2は正本の観点ヒント後に受付DB導入へ変更しました。設計への影響：受付直後に状態取得APIが受付済みを判別できませんでした。queue自体の耐久性不足と断定しないでください。DBへ書ける条件を明示し、受付成功の意味と永続的なjob記録について、まず現在の説明を聞いてください。必要なところから一つずつ、Default→Why→Trade-off→Exception→Production→Troubleshootingで説明・具体例を使い学び直してください。最後にDB commit後・publish前とpublish後・DB更新前の停止を別例で問い、再開と重複の扱いを確認してください。初回独力とヒント・解説後を区別し、図JSONの読解と描画確認を分け、その場の答え直しだけで定着済みにしないでください。口頭learnは40分付近で区切りを提案してください。終了時は既存テンプレートのYAML＋Session narrativeで [Session Sync] GitHub IssueをMFQWKMR4/tech2026に作成し、URLを返してください。summaryに元テスト2026-09-10-int-burst-01-01、R1〜R3、今回の回答・支援・残った課題を残してください。作成できない場合は未作成と明示し、コピー可能なタイトルと本文を返してください。B：外部副作用の結果不明と保証の限界
Section titled “B：外部副作用の結果不明と保証の限界”この学習でカバーする不足：R6の自前exactly-once案が未解決だった境界と、R7の説明後のat-most-once選択。R4のID安定性は未確認事項として必要な範囲で確かめる。
https://github.com/MFQWKMR4/tech2026 のCHATGPT.md、AGENTS.mdと次のファイルを読んでください。- sessions/2026-09-10-int-burst-01-01.yaml- src/content/docs/practice/reflections/2026-09-10-int-burst-01-01.md- reviews/architecture-api-idempotency.yaml- src/content/docs/architecture/api-idempotency.mdx- src/content/docs/architecture/queues.mdx- diagrams/architecture-queues/external-effect.jsonsession_type: learnで、architecture-api-idempotencyの不足を補う口頭学習を始めてください。今回カバーする不足：R6ではkey非対応の外部成功と自DB保存の境界を自力で整理できず、R7のat-most-once選択は解法説明後でした。設計への影響：結果不明で再実行すると二重副作用、再実行を抑えると未実行のまま残る可能性があります。最初に現在の説明を聞き、必要なところから一つずつDefault→Why→Trade-off→Exception→Production→Troubleshootingで学び直してください。provider keyとstatus queryのあり・なしは明示した別条件として扱い、過去の出題条件へ遡及しないでください。ローカルDBのclaimと外部効果を分け、同じ操作で安定したIDが必要な理由、結果不明・照合・手動復旧・補償・UXを必要に応じて説明してください。最後に同じDB記録で外部未実行/成功済みの二例を出し、retryと保留の選択を理由付きで説明できるか確認してください。初回独力とヒント・解説後を区別し、その場の答え直しだけで定着済みにしないでください。図JSONの読解と描画確認を分けてください。口頭learnは40分付近で区切りを提案してください。終了時は既存テンプレートのYAML＋Session narrativeで [Session Sync] GitHub IssueをMFQWKMR4/tech2026に作成し、URLを返してください。summaryに元テスト2026-09-10-int-burst-01-01、R4〜R7、今回の回答・支援・残った課題を残してください。作成できない場合は未作成と明示し、コピー可能なタイトルと本文を返してください。