テンプレートの中身
- ノード数
- 10
- パック
- 技術スタックデータ
- カテゴリ
- アーキテクチャ
Free プランで使えます：ダイアグラムあたり 15 ノード＋メモ・テキスト・ステッカー・マインドマップのトピック 150。
イベント駆動アーキテクチャでは、サービスは互いを直接呼び出す代わりに、起きたことを知らせ、ほかのサービスがそれに反応します。このテンプレートでは checkout-service がイベントブローカーの orders トピックに OrderPlaced を発行し、payment-service と inventory-service がそのトピックを購読します。
続いて payment-service が payments トピックに PaymentCaptured を発行し、shipping-service と notification-service がそれを受け取ります。処理できないイベントはデッドレターキューに入り、分析用ウェアハウスはすべてのイベントを受け取ります。左にプロデューサー、中央にブローカーとトピック、右にコンシューマーを置いているので、流れは左から右へ読めます。
使いどころ
- 注文、支払い、出荷などのビジネスイベントにサービスがどう反応するかを設計するとき。
- どのチームがどのイベントを発行し、誰がそれに依存しているかを示すとき。
- リトライ、デッドレターキュー、再処理といったエラー処理を見直すとき。
- リクエストとレスポンスの API に慣れた人に、非同期のシステムを説明するとき。
使い方
トピックとイベントの名前をドメインに合わせて変えます。イベント名は OrderPlaced のような過去形にします。
技術スタックパックからプロデューサーとコンシューマーを追加し、破線のエッジでトピックにつなぎます。
失敗しうるコンシューマーごとにデッドレターキューを追加し、分析用ウェアハウスが保存するイベントを書き留めます。
イベントを発行または利用するすべてのチームと図を共有し、トピックやイベントが変わったらバージョンを保存します。
よくある質問
このテンプレートは Kafka 専用ですか？
いいえ。ブローカーのフレームは一般的なので Kafka と書いていますが、同じ図は RabbitMQ、Amazon EventBridge、Google Cloud Pub/Sub、Azure Service Bus にも使えます。フレームとトピックの名前を変えてください。
デッドレターキューとは何ですか？
デッドレターキューは、コンシューマーがリトライしても処理できなかったイベントを保管します。イベントは失われず、後ろのイベントを止めることもありません。チームはそれを調べて原因を直し、再処理します。
イベントとリクエストの流れを 1 つの図で示せますか？
はい。直接の呼び出しには実線、イベントには破線のエッジを使うか、API ゲートウェイとイベントバスを一緒に示すマイクロサービスのテンプレートから始めてください。
関連テンプレート
関連するユースケース
クラウドアーキテクチャ図