バックエンド設計の11パターン：モノリスからSaga・BFFまで
概要¶
バックエンドアーキテクチャの主要 11 パターンの概要。システムデザイン面接や設計判断の場で使う共通語彙として整理。
詳細¶
1. Monolith（モノリス）¶
- 全機能が 1 デプロイ単位
- 採用場面: 小規模チーム・初期フェーズ・社内ツール
- トレードオフ: シンプルだが、スケールと独立デプロイが難しい
2. Microservices（マイクロサービス）¶
- 機能を独立したサービスに分割
- 採用場面: チームが大きく、機能ごとに独立したスケールが必要な場合
- トレードオフ: 分散システムの複雑さ（ネットワーク、整合性）が増す
3. Event-Driven（イベント駆動）¶
- サービス間はイベントで非同期通信（Kafka, SQS 等）
- 採用場面: 高スループット・疎結合が必要な場合
- トレードオフ: デバッグが難しい、結果整合性
4. Serverless（サーバーレス）¶
- 関数単位でデプロイ、実行時のみ課金（AWS Lambda 等）
- 採用場面: 使用頻度が低い・不規則なワークロード
- トレードオフ: コールドスタート、長時間処理に不向き
5. Layered Architecture（レイヤードアーキテクチャ）¶
- MVC の延長線上にある最もポピュラーなパターン6. Clean Architecture¶
- 依存方向を内側（ビジネスロジック）へのみ向ける
- Domain → Use Case → Interface Adapters → Frameworks
7. Hexagonal Architecture（ポート＆アダプター）¶
- ビジネスロジックを外部依存（DB・UI・外部API）から分離
- テスト容易性が高い
8. CQRS（Command Query Responsibility Segregation）¶
- 読み書きのスケール要件が異なる場合に有効9. Saga Pattern¶
- マイクロサービス間の分散トランザクションを管理
- 補償トランザクションで整合性を保つ
10. API Gateway¶
- クライアントと複数サービスの間に立つ単一エントリポイント
- 認証・レートリミット・ルーティングを集約
11. BFF（Backend for Frontend）¶
- フロントエンドの種別（Web・モバイル）ごとに専用バックエンドを用意
- 各クライアントに最適化したレスポンスを返せる
なぜ重要か / いつ使うか¶
- システムデザイン面接で「どのアーキテクチャを選ぶか」の回答軸として
- 新機能追加や既存システム改善のアーキテクチャ議論のとき
- 「このシステムにマイクロサービスは必要か？」の判断材料として