マイクロサービス面接の質問

文責 Aaron Cao · 更新 2026-09-04

マイクロサービス面接では、フレームワークの細かい知識よりもサービス境界、通信方式の選択、データ整合性、障害対応が問われる。モノリスの分割、同期呼び出しと非同期メッセージングのどちらを選ぶかの説明、サービス間でデータを正しく保つ方法、そして一つのリクエストを最初から最後まで追う説明を求められると考えてよい。

マイクロサービス面接は実際に何を試しているのか

パターン名は一通り頭に入っていて、サーキットブレーカーが何をするかも説明できる。それでも面接官が何を聞き取ろうとしているのかが分からない。ここでは面接官が評価する四つの領域を、通常尋ねられる順に示す。どれも語彙を問う体裁をした判断力の質問である。

分解。どこで境界を切るのか、なぜそこなのか。面接官が求めるのは、技術レイヤーではなくビジネス機能やデータ所有権に沿った境界である。
通信。同期のリクエスト/レスポンスか、非同期のイベントか、それぞれどこで破綻するか。求められる答えはトレードオフであり、好みではない。
データ。サービスごとに一つのデータベースを持つということは、サービス間の結合も分散トランザクションもないということだ。それでもシステムの整合性をどう保つのか。
運用。デプロイ、バージョニング、トレーシング、そして一つのサービスが落ちるのではなく遅くなったとき、夜中の三時に何が起きるか。

いずれもフレームワークの話ではないことに注目してほしい。なぜ注文確定を在庫管理から分離したのかを説明できる候補者は、アノテーションを列挙するだけの候補者より常に高く評価される。

分解と通信について最もよく聞かれる質問は何か

これらはほとんどのマイクロサービス面接の冒頭で聞かれる質問であり、それぞれの裏で面接官が何を確認しているかを示す。

このモノリスをどうサービスに分割しますか。ビジネス機能とデータ所有権に沿って切るのか、それともcontroller、service、repositoryといったレイヤーに沿って切るのかを確認している。後者の答えは分散モノリスを生む。
二つのサービスはどう通信しますか。それぞれの選択のコストを言葉にできるかを確認している。同期呼び出しはシンプルなメンタルモデルを与える一方で可用性を結合させ、非同期イベントは可用性を分離する代わりに結果整合性をプロダクトオーナーに説明する必要が生じる。
分散モノリスとは何で、どう避けますか。常に一緒にデプロイしなければならないサービスは、本当の意味で分離されていないと理解しているかを確認している。
サービスはどのくらいの大きさにすべきですか。具体的な数字に頼らずにいられるかを確認している。サイズは境界とそれを所有するチームに従う。
APIゲートウェイは必要ですか、何をするものですか。ルーティング、認証、レート制限をビジネスロジックから切り離せるかを確認している。
サービス同士はどうやって互いを見つけますか。サービスディスカバリの基本的な理解と、ハードコードされたホストがスケールした環境でなぜ破綻するかを確認している。

どの回答でもトレードオフを声に出して言うこと。頭の中だけで済ませた比較に、面接官は点数をつけられない。

データと障害についての質問にはどう答えるべきか

ここが面接の勝敗を分ける場所だ。これらの質問には綺麗な正解がなく、候補者はつい暗記した答えに頼ってしまう。

サービス間でデータの整合性をどう保ちますか。まず制約を明言する。サービスをまたぐトランザクションは存在しない。次にサガを説明する。イベントで振り付けする方式でも、コーディネーターがオーケストレーションする方式でもよいが、システムが結果整合性を持つこと、そしてその間ユーザーには何が見えるのかをはっきり言葉にする。
下流のサービスが遅いときはどうなりますか。タイムアウト、バックオフ付きのリトライ、そして遅い依存先がスレッドプールを使い果たさないようにするサーキットブレーカー。遅いことは落ちていることより厄介であり、そう言えることが本番運用の経験を示す。
リトライを安全にするにはどうしますか。冪等性だ。書き込み経路に冪等性キーを持たせれば、再送された決済も一度しか課金されない。
複数ステップのフローで部分的な失敗が起きたらどう対処しますか。ロールバックではなく補償アクションで対応する。返金や予約の解放が具体的にどう見えるかを説明する。
六つのサービスを経由したリクエストをどうデバッグしますか。すべてのホップを通じて伝播する相関IDによる分散トレーシングに加え、構造化ログとメトリクス。

あるパブリッククラウドベンダーのL5プラットフォーム職の面接を受けていたバックエンドエンジニアは、サガの質問に一度で答えたが、パターンの語彙で説明しただけで、顧客に何が見えるかには一切触れなかった。整合性が取れていない間、注文ページに何が表示されるのかという深掘りの質問こそが、実際に合否を決める。二つ目の答えまで用意しておくこと、一つ目だけでは足りない。

職種やトピック別の質問集は職種別の面接質問にまとめている。

これらを声に出して練習するにはどうすればよいか

このリストを読むと「知っている」感覚は得られるが、その感覚は見知らぬ相手に質問されて答えを待たれた瞬間に消え去る。パターンを知っていることと、多少のプレッシャーの中でそれを説明できることの間にある差こそが、システム設計面接の難しさのすべてであり、声に出して話すことでしか埋まらない。

注文処理や会員登録など、自分がよく知っているフローを一つ選び、境界、通信の選択、整合性の話、障害の話まで、分解全体を声に出して語ってみてほしい。文の途中で言い直さなくなるまで続ける。フォローアップの質問をしてくる相手に音声で答えるAI面接官を使って、この練習を模擬面接モードで試すこともでき、これはノートを読み返すよりも実際の面接に近い。

SubcueAIの創業者であるAaron Caoは、コンテンツの配信ではなく、この差そのものを中心に練習モードを設計した。質問リストならどこにでも無料で転がっている。候補者に足りないのは、相手が待っている中で答えを口にする回数だ。実際の面接中は、デスクトップアプリとブラウザ拡張機能のサイドパネルが、面接官が話している最中に構造化されたヒントを表示できるが、リハーサル済みの説明は、初めて読む説明に常に勝る。このアシスタントが何をして何をしないかはプロダクト概要で説明している。

よくある質問

マイクロサービスの質問はいくつ準備すればよいですか。

一つのフローを深く準備する方が、三十個の質問を丸暗記するより効果的だ。一つのシステムを分解し、通信方式の選択を説明し、整合性モデルを説明し、部分的な障害で何が壊れるかを述べられれば、面接官が聞いてくるほとんどのバリエーションに答えられる。

マイクロサービス面接ではKubernetesの知識が必要ですか。

ほとんどのバックエンド職では、クラスタを実際に操作する必要はなく、デプロイとスケーリングが何を提供すべきかを説明できればよい。プラットフォーム職やSRE職は事情が異なり、オーケストレーション、サービスメッシュ、ロールアウト戦略までさらに踏み込んで問われる。

これらの面接で最もよくある間違いは何ですか。

ビジネス機能ではなく技術レイヤーに沿って分割してしまい、一緒にデプロイせざるを得ないサービスを生んでしまうことだ。次によくあるのは、システムが結果整合性を持つと一言も言わずにサガを説明してしまうことである。

マイクロサービスの質問はコーディング面接と設計面接のどちらで聞かれますか。

多くは設計面接と、自分が担当したシステムについて聞かれるシニア向けの行動面接で問われる。コーディング面接はアルゴリズムと言語の習熟度に留まることが多いが、持ち帰り課題では既存のサービス群に一つサービスを追加するよう求められることもある。

AIアシスタントが本番でこれらの質問に代わりに答えてくれますか。

面接官が話している間に構造を提示することはできるが、それが最も役立つのはすでに内容を理解している場合だ。リハーサルの代わりにはならず、画面共有、録画されたセッション、監督付きテスト、会社支給のノートPCはいずれも対象外のままである。