Sailhouse

トピックはイベントを分類するバケツだ。slugで識別される1つのトピックにJSONイベントを発行すると、プラットフォームがそのトピックに付いた各サブスクリプションへ配る。イベントはメタデータも持ち、これを使ってトレースIDを付けたり、cron由来のイベントにスケジュールを載せたりする。トピックとサブスクリプションが2つの基本リソースで、他はその上に成り立つ。

Sailhouseは両方の配信方式を支える。プッシュサブスクリプションはイベント到着時にエンドポイントへPOSTを送り、5秒以内の200応答を求める。プルは逆で、ワーカーが自分のペースでイベントを要求する。課金サイクルや週次集計のような処理の重い仕事に向く。選ぶのはサブスクリプション単位なので、1つのトピックがリアルタイムのwebhookとバッチワーカーを同時に養える。

ウェイトグループは、並列のエージェント作業を実用的にする機能だ。発火させたいイベントの一覧と、完了時に通知するトピックを渡すと、Sailhouseが実行し、群全体が終わった時点で1つのイベントを発行する。これがないと、重複した確認や「もう全部終わったか」という競合しやすいループを書く羽目になる。プログラミング言語のwait-groupと同じ考え方を、リトライで余計な呼び出しが出ないイベント駆動の仕組みへ移したものだ。

Sailhouseはリソースを必要時に作る。存在しないトピックへイベントを送れば、与えたslugで作成し、そのイベントを格納する。プルサブスクリプションも同じように作れ、最長24時間の時間窓で、その間にトピックへ入ったものをまとめて引き込む。狙いはコードを書いてから出すまでのスキーマ手順を減らすこと。エージェントを反復して直すときに効いてくる。

作業を後ろへ回す方法は2つある。スケジュールイベントは単体のイベントかサブスクリプションに時刻を設定し、注文の14日後に支払いを処理したり、リマインダーを送ったりするのに便利だ。cronジョブは現在プライベートベータで、繰り返しのスケジュールでイベントをトピックへ発火する。時刻は常にUTCで、日次のまとめや毎時の利用量計算に使う。どちらも同じサブスクリプションモデルを使うので、別のスケジューラを覚える必要はない。

サブスクリプションフィルタを使えば、トピックを汎用に保ったままノイズとコストを削れる。1つのトピックを十数の狭いトピックに割る代わりに、JSONパスでサブスクリプション側を絞る。消費者は関心のあるイベントだけを見る。同じ層で流量制限と重複排除も支え、重複配信や暴走した発行元の急増に備えるガードをここに置ける。

SailhouseはTypeScriptとJavaScript、Go、Python（ベータ）、Rust（ベータ）の自社SDKを出し、それ以外にはCLIとREST APIを用意する。可観測性はイベントのトレースを扱い、トレースIDを付けてシステム全体でイベントを追える。ホスト型であるため取り込みリージョンは現在ロンドン、アッシュバーン、サンノゼに及び、データは中央で書き込まれ、通信時も保存時も暗号化される。