なぜThrottleではなくDebounceだったのか？ 700並列リクエストと戦うサーバーサイド実装のすべて by Yoshiori

ある日突然、あるサービスに急（きゅう）なスパイクアクセスがやってきました。その数、700並列。サーバーは悲鳴をあげ、DBは沈黙しました。

高負荷対策の定石といえば、キュー (Job Queue) を思い浮かべるかもしれません。しかし、安易にジョブを Queue に入れるだけでは、結局700並列の重い処理が非同期に実行されるだけ。そこから、いかにして本当に必要な処理だけを「間引く」かが本当の課題でした。

こうした処理の間引きには、一般的にスロットル (Throttle) が用いられます。では、なぜその一般的な手法である Throttle ではダメだったのか？ 本トークでは、似て非なる Throttle とデバウンス (Debounce) の違いを解説しつつ、サーバーサイドでの Debounce 実装に至るまでの道のりを赤裸々にお話しします。

単純な実装だったv1から、その改良版であるv2ですら対応できなかった現実の複雑なユースケース、そして最終的にたどり着いた動的な遅延制御ロジック(v3)まで――3度の再実装の過程を、v1からv3へと進化していく実際のコードを追いながら、その思考と共に解説します。

この実例で語る負荷制御の勘所と設計思想が、あなたの武器庫に加わる新たな一つになれば幸いです。