バックエンド開発者面接の回答

RESTの原則に従って設計します：リソースは名詞（動詞ではない）、URIは階層的でリソースの関係を表す、HTTPメソッドは意味的に使う（GET 読み取り、POST 作成、PUT/PATCH 更新、DELETE 削除）。非互換な変更を避けるために最初からAPIのバージョン管理を行います（/v1/）。レスポンス形式、エラーコード、ページネーションのパターンを一貫して設計します。OpenAPI/Swaggerでドキュメント化します。技術的に正しくても使いにくいAPIは良くないのでクライアントのニーズを設計時に考慮します。また、レート制限、認証、入力バリデーションを第一級の設計事項として扱います。

アクセスパターンに基づいてスキーマを設計します — 基本は正規化、クエリ性能が要求する場合に限って非正規化します。インデックスは戦略的に使用します：遅いクエリはすべて実行計画（explain plan）を確認し、選択性とクエリ頻度に基づいてインデックスを追加します。N+1問題はデータ層でのイーガーローディング設計により回避します。マイグレーションは慎重に行い、可能な限り後方互換な変更にし、破壊的なスキーマ変更にはブルーグリーンデプロイメント等の戦略を採用します。データ整合性のために、外部キー制約、NOT NULL制約、CHECK制約などをデータベースレベルで設けます。

最初からステートレスなサービス設計を行います — 状態はアプリケーションメモリではなくデータベースやキャッシュに置きます。非同期処理（メッセージキュー：RabbitMQ、Kafka、SQS）を同期である必要のない処理に使います。適切なレイヤーで積極的にキャッシュします：データベースクエリ結果（Redis）、集計結果、静的リソースなど。APIは水平スケールできるように設計し、独立してスケールするマネージドサービス（RDS、ElastiCache）を好んで使います。レート制限やバックプレッシャー対応も設計に組み込み、負荷時にサービスが優雅に劣化するようにします。

認証はOAuth 2.0 / OIDCをユーザー認証に、サービス間はAPIキーやJWTを使います。すべての入力を検証・サニタイズし、ユーザー入力から直接SQLを組み立てることはしません。濫用防止のためにレート制限やスロットリングを実装します。HTTPS/TLSを全域で使用し、証明書の検証を強制します。最小権限原則を適用し、各サービスとユーザーに必要最小限の権限を与えます。権限の使用状況は監査します。CIでは依存関係の脆弱性をスキャンします（OWASP Dependency-Check、Snyk）。認証失敗や権限昇格などのセキュリティイベントは中央でログに記録して監視します。

エラーはログに記録し、分類し、意味のある形で返すという方針に従います。構造化ログ（JSON）を適切なログレベルで出力し、ログの検索を可能にします。分散トレーシング（OpenTelemetry）を導入してリクエストをサービス間で追跡できるようにします。エラーコードはAPI全体で一貫して定義し、ドキュメント化します。CPUなどの技術的指標だけでなく、エラー率の異常に対してアラートを設定します。マイクロサービス環境では、依存が劣化したときの連鎖障害を防ぐためにサーキットブレーカー（Resilience4j、Hystrix）を実装します。

両方の構築・運用経験があります。モノリスは過小評価されがちで、開発・テスト・デプロイがシンプルで、多くのチームは特定のスケーリングやチーム調整上の制約に直面するまでマイクロサービスを必要としません。マイクロサービスへ移行する際はストラングラーフィグパターン（Strangler Fig pattern）を適用し、稼働中のモノリスからサービスを段階的に抽出していき、ビッグバン的な分割は避けます。マイクロサービスはサービスディスカバリ、分散トレーシング、ネットワーク障害モード、サービス間のデータ整合性など運用上の複雑さを大きく導入するため、利益が明確に上回る場合にのみその複雑さを受け入れます。

ビジネスロジックには分離したユニットテストを書き（データベースや外部依存はモックします）、サービスを実際の（テスト用）データベースに対して検証する統合テストも書きます — これによりリクエスト/レスポンスのサイクル全体をテストし、ユニットテストでは見逃しがちなSQLエラー、クエリ性能問題、データマッピングの問題を検出します。サービス間で公開されたAPIを他チームが消費する場合はコントラクトテスト（Pact）を使います。性能が重要なエンドポイントには負荷テスト（k6、Locust）を書きます。テストカバレッジは、本当に現実の障害を検出できるテストである場合にのみ意味があります。

RabbitMQやApache Kafkaを用いたイベント駆動システムの設計経験があります。トレードオフは理解しています：at-least-onceとexactly-once配信、コンシューマグループパターン、デッドレターキュー、メッセージの順序保証など。メッセージスキーマは慎重に設計し、本番での後方互換なスキーマ進化が不可欠であることを重視します。重複メッセージでデータ破損が起きないように冪等なコンシューマを実装します。運用指標としてキューの深さやコンシューマのラグを監視します。イベント駆動アーキテクチャは高いスケーラビリティと疎結合を実現しますが、スキーマ管理と障害処理に対する厳格な運用が必要です。