O limite de 10 por minuto que deixou passar muito mais.

Configurei um limite de 10 pedidos por minuto e vi passar bem mais que 10. A configuração parecia certa no código. Sob uma rajada rápida, o comportamento foi diferente do esperado.

O caso aconteceu num produto que ainda não apresentei aqui. O binding de Rate Limiting dos Cloudflare Workers conta por local, e essa forma de contar deixou passar rajadas acima do limite configurado. Para organizar a arquitetura, precisei separar o limite aproximado do limite que precisa ser exato.

O número configurado precisa de um teste

Um limite escrito na configuração comunica uma intenção, mas não prova a retenção real. Para saber o que acontece sob rajadas, é preciso disparar requisições em sequência e contar o retorno. Foi nesse teste prático que o limite de 10 por minuto aceitou bem mais que 10.

A contagem por local explica esse comportamento do binding em borda. Como os pedidos chegam a instâncias diferentes da rede, cada nó mantém sua própria fatia da contagem. Quando a regra de negócio exige precisão absoluta, esse modelo distribuído deixa passar picos indesejados.

O binding continua bom para limites folgados, como 60 por minuto na API geral. Nesse cenário, pequenas variações temporárias não afetam a segurança da aplicação. A contagem aproximada atende perfeitamente quando o objetivo é apenas conter abusos grosseiros.

Para um limite que precisa ser exato, como login e envio de código, a exigência é diferente. Nessas rotas sensíveis, qualquer brecha em rajada compromete a regra de segurança. Ali a contagem precisa de um único ponto centralizado de verdade.

O contador exato usa um Durable Object

Para os limites que precisam ser exatos, troquei o binding por um Durable Object com SQLite. Ele conta por IP com hash e libera a passagem se o objeto falhar. Um IPv6 conta pelo seu /64.

Essa regra garante que uma eventual falha no objeto libere a passagem sem travar a navegação. O contador exato opera enquanto o Durable Object responde normalmente. Se houver falha de infraestrutura, a requisição passa sem gerar um erro inesperado.

A identificação precisa tratar cada protocolo de forma adequada. O hash do IP isola a origem sem armazenar o endereço original no banco local. No IPv6, agrupar pelo bloco /64 evita que um mesmo remetente contorne o limite apenas rotacionando endereços da mesma faixa.

Esse desenho centraliza a contagem de forma consistente. Cada tentativa de autenticação consulta o mesmo estado compartilhado no Durable Object. O controle deixa de depender de replicações assíncronas entre pontos da rede.

A rajada precisa passar pelos dois protocolos

A prova está em produção: 10 aceitos e 30 recusados, tanto em IPv4 quanto em IPv6. O teste confirma que a regra atua nos dois caminhos em vez de assumir que o resultado de um representa o outro. Essa checagem direta afasta qualquer suposição sobre a borda.

Num teste, uma máquina com IPv4 e IPv6 conta como dois clientes. Use curl -4 e curl -6. Testar apenas um dos protocolos deixaria metade das rotas sem validação real.

A verificação separada impede falsos positivos no diagnóstico. Se o teste alternar entre protocolos durante os disparos, o contador enxerga duas origens distintas e aceita o dobro de requisições. Rodar cada bateria de testes de forma isolada garante a medição correta.

Essa separação comprova o funcionamento exato da proteção. Os dois mecanismos têm papéis bem definidos na infraestrutura de borda. O teste com rajadas confirma que a regra de bloqueio atua exatamente no limite configurado.

A conferência continua nos outros produtos

Registrei o caso numa lista de alertas da stack comum, com onde foi provado e o que conferir nos outros produtos. Um usa o mesmo binding com o limite do Better Auth desligado. O Garfim ainda não foi conferido.

Os dois ficaram anotados na lista de alertas da stack comum para acompanhamento. Essa documentação define qual operação está protegida, qual mecanismo conta e se aquele limite precisa ser exato. Uma regra que protege a API geral não deve ser assumida como suficiente para rotas de login.

A conclusão técnica é sempre medir a passagem real sob rajada nos dois protocolos. O número na configuração só ganha valor prático quando o teste confirma o comportamento esperado. Outro problema compartilhado que registrei na mesma stack está no relato sobre conexões presas atrás do Hyperdrive.