イベント駆動アーキテクチャ — ピストルが鳴った瞬間だけ走り出す運動会

ネットショップで注文が入ると、確認メールを送る、在庫を引き当てる、ポイントをつける、といった仕事が一斉に始まります。問題は、それぞれの係が「注文が入った」ことをどうやって知るかです。

1つは、係が注文サービスへ「新しい注文ある?」と定期的に聞きに行くやり方(ポーリング)。もう1つは、注文が入った瞬間に注文サービスが合図を鳴らし、聞いた係が走り出すやり方です。これがイベント駆動。運動会で、走者が何度もスタートを確認しに行くか、ピストルが鳴った瞬間だけ走り出すかの違いです。図1で、2つの待ち方を比べてください。

聞きに行く間隔は、速さと無駄のつり合い

ポーリングで注文を入れると、係が走り出すのは次に聞きに行ったときです。間隔が3秒なら、平均で1.5秒ほど遅れます。間隔を0.5秒に縮めれば速くなりますが、注文が入っていない時間も聞きに行き続けるので、空振りが一気に増え、注文サービスは問い合わせの対応に追われます。速くしたいほど無駄が増えるのがポーリングの弱点です。

イベント駆動にすると、注文が入ったその瞬間に3人が走り出し、空振りは0回になります。しかも注文サービスは「注文が入った」と鳴らすだけで、誰が聞いているかを知りません。あとから「ギフト包装係」を増やしても、注文サービスは書き換えずに済みます。

合図は一瞬。聞き逃したら終わり

ただし、合図には弱点があります。「😴 ポイント係が休憩中」をオンにして、イベント駆動で注文を入れてみてください。ピストルは鳴ったその瞬間にしか聞こえないので、休憩していたポイント係は注文があったことを永遠に知りません。ポーリングなら、戻ってきてから聞きに行けば「今の注文一覧」が分かるので、こういう聞き逃しは起きません。

そこで実際のシステムでは、合図をそのまま流すのではなく、起きた出来事を順に記録しておく(イベントログ)仕組みを間に置きます。「📼 合図を記録して残す」をオンにすると、休憩から戻った係は記録を読んで続きから仕事を再開できます。Kafkaのようなイベント基盤が、この役目を担います。

まとめ

イベント駆動は、何度も聞きに行かず、出来事が起きた瞬間に動き出す作り方です。速く、無駄な問い合わせがなく、出す側は受け取る側を知らなくていい。そのかわり合図は一瞬なので、止まっていた係のために出来事を記録しておく仕組みが欠かせません。ピストルを鳴らすだけでなく、何回鳴ったかを書き留めておくのが、イベント駆動を安心して使うコツです。