Sidekiqによる、細分化されたワーカーを実行する仕組みは、ジョブの失敗をリカバリーすることに対しても強みを発揮しています。
あるサーバがメンテナンス中で接続できなかった場合、そのサーバに投稿を配送しようとすると失敗します。
このとき、投稿の配送をひとかたまりの処理として一回で実行するようになっていると、その時に繋がらないサーバにはもう配送するチャンスがなく、ダメだったら無視されてしまいます。
Sidekiqを使った仕組みでは、失敗したジョブだけを再実行することができます。
しかも、すぐにやり直しても失敗するので、失敗したら少しずつ間隔をあけていきます。
3時間後につながらなかったら、半日後にもう一回試す、というように、相手側が復旧するかもしれない時間を待つようにつくられています。
これにより、復旧したサーバにも配送が届くようになります。
あまりにも長くつながらなかったら、最後には諦めるようになっています。
連合を柔軟に運用できるようにするための、重要な仕組みです。
ジョブは短時間で実行できる単位に分割します。
そうしないと、ひとつのジョブが長時間占有しつづけることとなり、効率良く他のジョブを同時実行できなくなります。
また、ある処理を実行しているうちに、他の処理の影響で実行に失敗することも起きます。
たとえば、お気に入りしようとした投稿が、何かの都合でもう削除されているかもしれません。
ひとつのジョブが大きすぎると、こういう状況の変化に対応するのが難しくなります。
--
さて、リモートから誰かの投稿がやってきました。
この投稿者をこのサーバでは100人がフォローしているので、100人のタイムラインに投稿を流さねばなりません。
この時まず、リモートサーバから来たActivityの内容を確認するワーカーを実行します。投稿者Aの新規投稿であると解析されました。
次に、この投稿を各タイムラインに配送するワーカーを実行します。
やることの多いワーカーですが、公開範囲を確認し、公開タイムライン（連合、ハッシュタグなど）に流す処理、フォロワーのホームやリストに流す処理を行います。
このうち、フォロワーは人数が多いので、一人ずつのホームとリストそれぞれで100以上のワーカーに分割して走らせます。
難しいかと思いますが、なんとなくイメージできますでしょうか？
