サーキットブレーカーパターンという奴がありまして、MastodonではStopLightというgemが使われています。StopLightっていうのは信号機のことです。
たくさんのサーバ同士が相互に通信しあう仕組みのActivityPubでは、どこかのサーバでエラーが発生すると、そこに繋ごうとしたサーバでエラーが発生することになります。
このエラーに適切に対処できないと、巻き込まれて死んだり、処理が詰まってサーバ全体の動作がおかしくなったりします。
個別のジョブ（例えばある投稿を相手サーバのフォロワーに届ける）は、失敗したら、時間をおいて再試行するようになっています。この仕組みは再試行パターンという奴で、ジョブを捌くsidekiqが担っています。
さて、個別にはそれでいいのですが、全体としては、死んでいるサーバに対するジョブが次々と生成されていきます。
当面は失敗することが予想されている時は、復活しているか時々チェックするぐらいにとどめて、いちいち試さずに最初から再試行送りにした方が効率的です。これを行っているのがStopLigitです。
All Pleroma servers have a built-in relay, eg https://gleasonator.com/relay It makes hosting a bit easier.
@alex Pleroma is easy to understand with the built-in actors available. Mastodon is a bit more complicated.
From the standpoint of implementing relays, the bottleneck is that Pleroma does not do JSON-LD signatures. Everything needs to be delivered via Announce Activity, so there will be a lot of fetching between servers. Signed Objects can be transferred directly, so the load is less.
さて本題。
Mastodonのリレーであるpub-relayは、最初の頃はsidekiqを使っていたのですが、途中でジョブキューを使わない仕組みに変更されました。
リレーは失敗したジョブを再試行しない（即座にあきらめちゃう）ので、sidekiqを使わなくても大丈夫ではあるのですが、このことで、失敗した場合の対応に弱くなっていました。
どこかのサーバが障害を起こしていると、リレーの処理が詰まるのです……。
そこで、サーキットブレーカーを導入しました。
Crystalでは、Rubyでいうところのgemに相当するshardというのがありまして、そこで公開されているcircuit_brakerというshardを利用しています。