レートリミットの設計

制限を超えた場合、HTTPステータスコード 429 を返し、リクエストを受け付けないようにする。 タイムウィンドウを定義し、リクエスト数を定義する。(例: 100リクエスト/分) もしリクエスト数が超えた場合はサーバーが即座に 429 を返す。Retry-After などを見て待機するのはクライアント側の責務である。 複数のサーバーでカウントする場合、Redisのようなインメモリデータベースを使用する。

固定ウィンドウ方式で 1 分あたり 100 リクエストを許可する場合、前のタイムウィンドウの最後10秒間に100リクエスト、現在のタイムウィンドウの最初10秒間に100リクエストがあると、わずか20秒間に200リクエスト送れてしまう（境界バースト問題）。

トークンバケットアルゴリズムはこの固定ウィンドウの問題を解決する。 あらかじめ容量（トークン数）が決められており、消費すると時間ごとに補充されていく。 スライディングウィンドウログ、スライディングウィンドウカウンタ、リーキングバケットも同じ問題を解決する。

クライアントアプリケーションでレートリミットを実装する。ただし、悪意のあるユーザーはこれを回避する方法を探す。 サーバーサイドでレートリミットを実装する。全てを1箇所にまとめることができるが、ビジネスロジックと混在する。 ミドルウェアでレートリミットを実装する。API Gatewayにより、ビジネスロジックを分離し、ポリシー管理するための場所ができるが、システムが複雑になる。 ミドルウェアで実装するのが多くの場合、バランスがいい。Gateway API/Reversee Proxy + Redis を中間に挟むのはよい構成である。