🦔
同期・非同期の設計方針が妥当で、業務要件を満たしているか？
同期・非同期の設計方針が妥当で、業務要件を満たしているか？
背景・概要
同期処理はリアルタイム性・一貫性を優先し、非同期処理はスケーラビリティや耐障害性を重視する
要件に応じた使い分けが設計品質に直結する
例
- 決済や在庫引当など整合性必須の処理は同期で行う
- メール送信や通知処理は非同期ジョブに切り出す
- API はリクエスト完了後にレスポンスを返すが、裏でドメインイベントが発行されて処理が継続する（CQRSの一種）
よくある失敗例
- ユーザーに非同期ジョブの完了を待たせ、UXを悪化させる
- 非同期イベントの送信失敗時にリカバリが用意されていない
- 非同期の副作用が後から発火して一貫性が保たれずエラーが起きる
FAQ
Q. 処理のどこまでを同期に含めるべき？
A. ユーザーが即時で結果を知る必要のある処理までに限定し、それ以外は非同期で遅延処理するのが無難
Q. 非同期処理でエラーが起きた場合、どこで検知する？
A. 処理結果を明示的に**保存 or 通知する構造（ステータス管理、死活監視）**を用意すべき。監視と再実行の設計は必須
関連観点
📘 本記事は SaaS設計レビュー観点チェックリスト（2025年版） の一部です。
設計観点カテゴリ：🔁 イベント・非同期処理
レベル：Structure（構造・原則・責務整理レベル）
推奨読者：設計初心者 / 設計中のチーム / レビュワー
🧭 他の観点もまとめて読みたい方はこちらからどうぞ。
Discussion