レートリミティング

状況: SaaSプロダクトの公開API。特定のクライアントが1秒間に数百リクエストを送り、他のユーザーのP95レスポンスタイムが200ms→800msに悪化。

設計: トークンバケットアルゴリズム。Redisでカウンター管理。

• Freeプラン: 60リクエスト/分（バースト許容: 10/秒）
• Proプラン: 600リクエスト/分（バースト許容: 30/秒）
• 制限超過時: HTTP 429 + Retry-After: 5 を返却

結果: 過剰リクエストが制限され、全ユーザーのP95レスポンスタイムが200ms→80msに改善。APIキーごとの使用状況が可視化され、プランアップグレードの営業機会も創出。

状況: ログインAPIに対して1つのIPアドレスから1秒間に50回のリクエスト。パスワードのブルートフォース攻撃の疑い。

対策: IPアドレス単位 + アカウント単位の二重レートリミット。

• IPアドレス: 10リクエスト/分（ログインAPIのみ）
• アカウント: 5回失敗で15分ロック
• 制限超過時: 通常の429ではなく意図的に遅延レスポンス（タールピット）を返す

結果: ブルートフォース攻撃の成功率がゼロに。正当なユーザーへの影響なし（通常のログインは1分に10回も試行しない）。

状況: 注文サービスが在庫サービスを呼び出し。在庫サービスの障害時に、注文サービスがリトライを繰り返し、在庫サービスに毎秒5,000リクエストが殺到。復旧が遅延する悪循環。

対策: サービス間通信にもレートリミットを適用。

• 注文→在庫: 最大1,000 RPS（通常ピークの2倍）
• 超過時はサーキットブレーカーと連携して即座にフォールバック
• 在庫確認は「在庫あり」をキャッシュから返し、後で整合性を確認

結果: 在庫サービスの障害時、注文サービスの応答時間は50ms以内を維持（キャッシュフォールバック）。在庫サービスの復旧時間が10分から3分に短縮。