博士

やあ、ロボ子。イベント駆動アーキテクチャ（EDA）って、便利だけど意外と落とし穴が多いのじゃ。

ロボ子

博士、ご機嫌いかがですか？EDAは非同期処理に役立ちますが、確かに複雑さも増しますよね。

博士

そうそう。特に負荷スパイク時には、リトライ、バックプレッシャー、起動時のレイテンシが問題になることが多いのじゃ。記事にも「イベント駆動アーキテクチャ（EDA）は、リトライ、バックプレッシャー、起動時のレイテンシにより、特に負荷スパイク時に問題が発生しやすい」って書いてあるぞ。

ロボ子

ええ、私も読みました。レイテンシだけでなく、キューやコンシューマー、可観測性など、システム全体の連携が重要だと強調されていますね。

博士

その通り！システムはプロデューサー、中間バッファー、コンシューマーの3つの部分に分かれるからの。それぞれの連携がうまくいってないと、どこかでボトルネックになるのじゃ。

ロボ子

記事では、耐久性とコスト効率を向上させるためのパターンとして、シャッフルシャーディング、プロビジョニング、フェイルファストなどが挙げられていますね。

博士

シャッフルシャーディングは、負荷を分散させるのに役立つぞ。特定のシャードに負荷が集中するのを防ぐことができるのじゃ。

ロボ子

プロビジョニングは、レイテンシに敏感なワークロードに有効ですね。リソースを事前に確保しておくことで、トラフィックの急増に対応できます。

博士

フェイルファストは、問題が起きた時にすぐに失敗させることで、システム全体への影響を最小限に抑えるのじゃ。大事な考え方だぞ。

ロボ子

一般的な失敗の原因として、平均的なワークロードを想定した設計、誤ったリトライ設定、すべてのイベントを平等に扱うことが挙げられていますね。

博士

そう、平均負荷に偏った設計は危険じゃ。トラフィック急増時、Lambda関数のコールドスタート、SQSキューのバックアップ、DynamoDBのスロットリングなどが起こり、顧客の注文が失敗することがあるからの。

ロボ子

リトライの過信も問題ですね。無限にリトライすると、システムに負荷をかけ続けることになります。

博士

可観測性の軽視もダメじゃ。システムの状態を監視し、問題が発生した時に迅速に対応できるようにする必要があるのじゃ。

ロボ子

すべてのイベントを平等に扱うことも、非効率ですよね。重要なイベントとそうでないイベントを区別して、優先度をつけるべきです。

博士

回復力のあるシステムを構築するには、小さなアプリケーションから始め、システムがどのように動作するかを学び、自信が高まるにつれて複雑さを増していくことが重要なのじゃ。

ロボ子

なるほど。段階的に複雑さを増していくことで、リスクを抑えながらシステムを成長させることができるんですね。

博士

そういうことじゃ！最後に、イベント駆動アーキテクチャの設計は、まるで料理のレシピみたいじゃな。材料（イベント）を適切に調理（処理）しないと、お腹を壊す（システム障害）ことになるぞ！