Pular para o conteúdo

apps/resiliency/rate-limiting

109 · Resiliência & Tolerância a Falhas · ≈ 6 min de estudo

Rate Limiting

Limita quantas requisições cada cliente faz numa janela de tempo, com o estado no Redis compartilhado por todas as réplicas. Protege o login contra força bruta, contém o custo de operações caras e impede que um cliente consuma a capacidade de todos. Responde 429 com Retry-After para o cliente saber quando tentar de novo.

passos
6
arquivos
5
testes
0
tecnologias
5
Infraestrutura realTypeScriptBunElysiaRedisDocker
Baixar cartão

Cenário

Um banco digital limita o envio de PIX a 10 por minuto por conta, o extrato a 30 por minuto e o login a 10 tentativas por IP e 5 por conta a cada 10 minutos. A chave do PIX é a conta, não o IP: um escritório inteiro sai pelo mesmo IP. No login, uma botnet que usa um IP por tentativa é barrada pela chave da conta. Com o Redis fora, o login fecha (429) e o extrato segue aberto.

Planta

Sequência
8/8
POST /pix (x-account-id)1EVAL janela deslizante (poda, conta, registra)2ok, restam 93201 RateLimit-Remaining 94POST /pix (11ª no minuto)5EVAL6bloqueado, libera em 60 s7429 Retry-After 608ClienteAPI PIXRedis
8

8 passos — reproduza para seguir o fluxo

Como funciona

6 passos

Rejeita o excesso acima da cota.

Esconde cada passo: lembre antes de tocar para revelar.

Vocabulário compartilhado

  1. 01

    limitCount roda um script Lua no Redis: remove entradas mais velhas que a janela, conta e registra num passo atômico

  2. 02

    A janela é um sorted set com o timestamp como score — desliza continuamente, sem o furo de 2× da janela fixa na virada

  3. 03

    Requisição bloqueada não é registradaInsistir não estende o bloqueio

  4. 04

    limitHeaders põe RateLimit-* em toda resposta e Retry-After só no 429

  5. 05

    O login consulta as chaves de IP (do cabeçalho do proxy próprio) e de conta (documento normalizado) e reporta a pior, com a mesma resposta para as duas

  6. 06

    Falha do Redis é decidida por rota: login e PIX em *fail-closed*, extrato em *fail-open*, sempre com log

Trade-offs

O que se ganha, o que se paga

4 vantagenscada ganho tem um preço4 custos

Vantagens

  • Limite vale para a frota inteira, não por réplica

  • Janela deslizante não deixa passar o dobro na virada

  • Dupla chave no login pega script único e ataque distribuído

  • Modo de falha por rota evita derrubar a API junto com o Redis

Custos

  • Cada requisição limitada custa uma ida ao Redis

  • Sorted set guarda uma entrada por requisição, mais memória que um contador

  • Bloqueio por conta pode ser usado para travar o dono legítimo

  • *Fail-open* deixa a rota sem limite enquanto o Redis estiver fora

apps/resiliency/rate-limiting

5 arquivos

src/

  • limiter_window.tsJanela deslizante atômica em Lua sobre sorted set
  • limit_contract.tsCabeçalhos RateLimit-* e Retry-After, e a pior de várias chaves
  • api_pix.tsAPI com PIX e extrato por conta, login com dupla chave e modo de falha por rota
  • config_rate.tsConfiguração validada do ambiente
  • demo.tsdemoRajada de PIX, ataque distribuído ao login e Redis fora

Executar · com Docker

  1. ./docker.sh up# sobe Redis
  2. bun install# dependências
  3. bun run demo# roda o cenário
  4. bun run test# integração contra o serviço real
Requisitos
BunDocker
Sobe junto
Redis

Por que se relacionam

Teste rápido

Qual é o próximo passo depois de Rate Limiter?

Próximo projeto · Resiliência & Tolerância a FalhasGraceful Degradation
Esc

↑ ↓ navegarEnter abrir191 resultados