アーキテクチャレビュー面接の対策：設計を全部作り直さず評価する

システム設計は白紙から作ります。アーキテクチャレビューでは、既存設計、経緯、制約が与えられ、目的に適しているかを判断します。存在理由を知る前に、自分の好きな技術へ置き換えないことが大切です。

利用者、絶対に失敗できないこと、現在の規模、今後の変化、固定制約を聞きます。その後、信頼性、セキュリティ、レイテンシ、開発速度、コストなどの優先度を書きます。

通常、ピーク、障害の三つのシナリオを使い、境界を越えるデータと制御を追います。所有者、整合性、容量、タイムアウト、再試行、観測、復旧を各段階で確認します。

図だけではリスクを証明できません。「決済事業者が課金後にタイムアウトすると、冪等性キーがない同期再試行で注文が重複する」のように、発生条件と結果を結びます。

リスク、発生条件、影響、現在の対策、変更案、検証を短い表にします。与えられた状況での影響と起こりやすさから並べます。世界規模の理論上の問題より、既知の運用ボトルネックが上になる場合もあります。

事実と推測を分けます。「図にはDBが一つだけ」は事実です。「可用性目標を満たせない」は、負荷、復旧、配置の証拠が必要な推測です。

日程を保存し、外部カレンダーを呼び、メールを送る処理が一つのリクエストに入っているとします。カレンダー登録後にDB保存が失敗した場合、再実行で予定が重複するか、同期遅延をユーザーが分かるかを確認します。

日程要求を先に保存し、冪等性キーつきの非同期処理でカレンダーへ反映し、保留状態を表示する案が考えられます。短時間は保留が見える一方、再試行と監査がしやすくなるという交換条件も話します。

「キューを追加」「マイクロサービス化」で止めません。合意したピークでの負荷試験、復旧訓練、障害注入、コスト比較、段階公開の指標など、判断を確かめる方法を言います。

最後に、現行設計の強み、上位二つのリスク、次の判断、必要な証拠をまとめます。建設的で、優先順位の見えるレビューになります。

Well-Architectedの全項目を読み上げる必要はありません。枠組みは確認漏れ防止に使い、指定された優先度を深掘りします。規模が分からなければ二つの条件分岐を示し、選択に必要な事実を言います。固定制約は一度確認した後、その範囲内で評価します。

敬意のある批評はリスクに直接的であり、知らない経緯には慎重です。どの言語でも、初めて会うチームの設計判断を扱う際に役立ちます。