スタッフ面接：40,000 RPS のサービスを 30 日で廃止する方法¶

原文¶

Interviewer for a Staff Backend Role:

You need to deprecate a service that handles 40,000 requests per minute. 17 other services depend on it.

6 of those teams have not responded to your migration emails in 3 weeks.

You have a hard deadline in 30 days. How do you shut this down without taking half the company's infrastructure with it?

要約¶

毎分 40,000 リクエスト・17 サービスが依存・無反応チームが 6 つ・30 日の締め切り。スタッフエンジニアとして「技術だけでなく組織を動かす」設計が問われる問題。段階的廃止・可観測性・エスカレーション・フォールバック戦略が鍵。

回答¶

方針：「停止」ではなく「安全な移行」として設計する¶

即日やること（Day 1-5）

全依存サービスの実際のトラフィックを計測 → 本当に使っているのか、どのエンドポイントかを把握
未応答チームのマネージャーにエスカレーション → メールより Slack + 上長への直接連絡
廃止スケジュールを Deprecation Notice として全体に告知（Slack / Confluence / 社内ポータル）

技術的な段階廃止戦略（Day 5-25）

Phase 1: Warning モード
  → 廃止予定エンドポイントへのリクエストに X-Deprecated: true ヘッダー付与
  → ログに警告を記録して依存サービスのオーナーに通知

Phase 2: シャドウモード
  → 新サービス（後継）にもリクエストを並列送信してレスポンスを比較
  → 差異があれば新サービスのバグを発見・修正

Phase 3: トラフィック移行
  → 機能フラグ or ロードバランサー設定で徐々に切り替え（10% → 50% → 100%）

Phase 4: 廃止サービスをリードオンリー化
  → 書き込みは受け付けない。読み取りのみ残す

Phase 5: 完全停止
  → 全依存の移行確認後にシャットダウン

無反応チームへの対応

週1でリマインダーを送る（CC: マネージャー、必要なら VP）
「移行しないとどうなるか」を具体的に伝える（サービスが 503 を返す日付）
最終手段：廃止サービスをメンテナンスページに切り替え、無反応チームのサービスが壊れるようにする（組織的な判断が必要）

フォールバック

廃止後 2 週間はスタンバイ状態で維持（クイックロールバック可能に）
監視アラートをセット（エラーレートが上がったら自動通知）

解説¶

スタッフエンジニアとして問われていること¶

この問題は技術問題ではなく 組織設計の問題。

観点	問われていること
技術	段階的廃止・フォールバック・可観測性の設計ができるか
コミュニケーション	無反応チームを動かすエスカレーション戦略
リスク管理	「半分のインフラを壊さずに」停止できるか
期限管理	30 日間のマイルストーン設計

→ 関連: スタッフエンジニアへの道、K8Sデプロイ設計判断

リンク¶

元ポスト