学習トピックを選ぶ
詳しい教材を順に読むための一覧ではなく、一つ選んで話し始めるための入口（基礎20題と実セッションから追加したテーマ）。 一般的なWebアプリの設計・運用で必要な基礎を選んだもので、面接出題頻度のランキングではない。 アルゴリズム問題や実装速度より、要件・理由・trade-off・障害時の判断を説明する。
迷ったらこの順で
Section titled “迷ったらこの順で”- DBの基礎：スキーマ → 索引 → 実行計画 → トランザクション。
- 設計の練習：要件確認 → 責務分割 → API → キュー。
- Productionの経験とつなぐ：可観測性 → 接続プール → ロック → 復元。
順番は必須ではない。過去のneeds_revisitがあれば、それを先に扱う。 Learnは概念から、Practiceは設計案から、Interviewは口頭の問いから始められる。 各ページに開始文がある。新規のSQL実験はまだなく、既存のIndex実験だけ実装済み。
Database — 10題
Section titled “Database — 10題”| トピック | 最初に考える問い |
|---|---|
| スキーマ・制約・正規化 | 小さなECサイトの顧客・注文・注文明細をどう分け、何をDBの制約で守りますか？ |
| 索引・複合索引の設計 | 顧客ごとの新しい注文20件を返すAPIに、どんなindexを検討し、効果をどう確かめますか？ |
| SQL・JOIN・実行計画 | 注文一覧に顧客名を表示すると急に遅くなりました。SQLとアプリのどちらから、何を確認しますか？ |
| トランザクション・分離レベル | 残り1個の商品を2人が同時購入します。どこを一つのtransactionにして、何を保証しますか？ |
| MVCC・ロック・VACUUM | CPUは低いのに更新APIが待ち続けています。MVCCがあるDBで、何が待ちの原因になり得ますか？ |
| 接続プール・同時実行制御 | APIサーバーを3台から30台へ増やしたところ、DB接続エラーが増えました。どう設計し直しますか？ |
| スキーマ変更・安全な移行 | 稼働中の注文テーブルに必須項目を追加します。新旧アプリが混在しても壊れない手順を説明してください。 |
| バックアップ・復元・RTO/RPO | バックアップ成功の通知はありますが、復元したことがありません。障害に備えて何を決め、何を試しますか？ |
| レプリケーション・読み取り整合性 | 注文作成の直後、一覧に注文が見えないことがあります。読み取りをreplicaへ分けた設計をどう見直しますか？ |
| データ増加・保持・分割の判断 | 履歴テーブルが毎月増え、検索と削除に時間がかかります。partitioningを入れる前に何を確認しますか？ |
Architecture — 10題
Section titled “Architecture — 10題”| トピック | 最初に考える問い |
|---|---|
| 要件確認・SLO・設計の出発点 | 予約サービスを作ってほしいと言われました。構成図を描く前に、何を誰に確認しますか？ |
| 責務分割・モノリスとサービス分割 | 5人チームで注文・在庫・請求を作ります。まずどう分割し、何が起きたらサービスを分けますか？ |
| HTTP API・冪等性・ページネーション | 注文作成APIでタイムアウトしたクライアントが再送します。契約とサーバー側の処理をどう設計しますか？ |
| キャッシュ・鮮度・無効化 | 商品詳細APIを速くするためcacheを導入します。何をどこに置き、どの程度古くてもよいと判断しますか？ |
| 非同期ジョブ・キュー・重複処理 | 注文完了メールと外部連携を非同期にします。ジョブをどこで作り、成功と失敗をどう扱いますか？ |
| 認証・認可・テナント分離 | 複数企業が使うSaaSで、ログイン済みユーザーが他社の注文IDを指定しました。どこで何を検証しますか？ |
| スケール・負荷分散・容量計画 | APIのtrafficが10倍になる予定です。サーバー増設で解決する部分と、先に調べる制約は何ですか？ |
| タイムアウト・再試行・障害の分離 | 外部決済APIが遅くなり、自分たちのAPIまで詰まりました。待ち時間と再試行をどう設計しますか？ |
| 可観測性・SLO・障害調査 | ユーザーは遅いと言っていますがCPUアラートはありません。どの観測から調査を始めますか？ |
| リリース・互換性・ロールバック | 新バージョンを無停止で出したいとき、リリース方式と中止条件をどう決めますか？ |