A Comparative Survey of API Rate-Limiting Algorithms: Token Bucket, Leaky Bucket, and Sliding Window
Este artigo pesquisa e compara experimentalmente cinco algoritmos de limitação de taxa de API amplamente utilizados — token bucket, leaky bucket, fixed window, sliding window log e sliding window counter — para avaliar seus compromissos em tolerância a rajadas e precisão, fornecendo, em última análise, orientação para a seleção do algoritmo mais apropriado com base em características específicas de tráfego e restrições do sistema.
Artigo original sob licença CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo
Os serviços digitais modernos dependem de um equilíbrio delicado entre disponibilidade e proteção. Quando milhões de pessoas tentam acessar um site ou um aplicativo ao mesmo tempo, os servidores por trás das cenas podem ficar sobrecarregados, muito parecido com uma ponte de pista única obstruída por um aumento repentino de tráfego. Para evitar esse colapso, os engenheiros utilizam um mecanismo chamado limitação de taxa (rate limiting), que atua como um porteiro. Este porteiro conta quantas solicitações um usuário ou dispositivo específico envia dentro de um determinado período e bloqueia quaisquer outras que excedam um limite seguro. O objetivo não é punir os usuários, mas garantir que o sistema permaneça estável para todos, impedindo que alguns usuários pesados consumam todos os recursos disponíveis. No entanto, nem todo o tráfego chega em um fluxo constante; às vezes, ele vem em surtos súbitos e agudos, como quando uma notícia popular surge ou um sistema tenta novamente uma conexão que falhou. O desafio para os engenheiros é decidir como lidar com esses surtos: o sistema deve permitir que um pico temporário passe ou deve aplicar estritamente um limite fixo, independentemente da situação?
Um estudo recente de Umair Saleem investiga as diferentes regras matemáticas usadas para construir esses porteiros digitais. A pesquisa foca em cinco métodos específicos que são comumente usados na indústria: o balde de tokens (token bucket), o balde vazante (leaky bucket), o contador de janela fixa (fixed window counter), o log de janela deslizante (sliding window log) e o contador de janela deslizante (sliding window counter). Cada um desses métodos tem uma maneira diferente de rastrear o tempo e contar as solicitações, levando a comportamentos distintos quando um surto de tráfego ocorre. Para entender qual método funciona melhor, o autor não se baseou apenas na teoria, mas construiu uma simulação de computador para testá-los todos sob condições idênticas. A simulação criou um fluxo realista de mais de mil solicitações ao longo de cem segundos. Este fluxo incluiu um fluxo de fundo constante de oito solicitações por segundo, interrompido por dois surtos distintos de atividade: um período de cinco segundos onde o tráfego saltou para quarenta solicitações por segundo, seguido por um pico mais agudo de dois segundos atingindo sessenta solicitações por segundo. Ao passar exatamente este mesmo padrão de tráfego por cada um dos cinco algoritmos, o estudo pôde medir exatamente quantas solicitações cada método aceitou, quantas rejeitou e como o sistema se comportou durante os picos.
Os resultados revelaram uma divisão clara em como esses algoritmos lidam com a pressão de um surto de tráfego. O balde de tokens e o balde vazante comportaram-se de maneira quase idêntica quando usados simplesmente para decidir se aceitavam ou rejeitavam uma solicitação. Ambos os métodos permitiram que o sistema absorvesse os surtos de forma mais eficaz do que os outros, aceitando um total de 844 solicitações das 1.057 enviadas, o que se traduz em uma taxa de aceitação de aproximadamente 80 por cento. Durante o primeiro grande surto, esses dois métodos permitiram a passagem de 69 solicitações e, durante o segundo surto, mais agudo, permitiram 38 solicitações. Isso aconteceu porque esses algoritmos são projetados com uma capacidade integrada de armazenar "permissão extra" para uso futuro, permitindo que suavizem os picos sem afastar os usuários imediatamente. Em contraste, o log de janela deslizante foi o mais rígido de todos os métodos. Ele nunca permitiu que mais de dez solicitações passassem em qualquer segundo individual, aderindo estritamente ao limite configurado. Embora isso tenha proporcionado a proteção mais precisa contra a sobrecarga, teve um alto custo: rejeitou o maior volume de tráfego no total, aceitando apenas 67,9 por cento das solicitações. Foi o único método que garantiu que o sistema nunca veria um pico acima do limite, mas o fez afastando usuários legítimos com mais frequência do que os outros métodos.
Os três métodos restantes ficaram em um meio-termo, mostrando falhas previsíveis baseadas em como mediam o tempo. O contador de janela fixa, que reinicia sua contagem no início de cada novo segundo, sofreu com um erro de tempo nos limites. Como ele podia reiniciar seu contador justamente quando um surto de tráfego chegava, permitiu um pico temporário de até quinze solicitações em um único segundo, o que era superior ao limite pretendido. O contador de janela deslizante tentou corrigir isso olhando também para o segundo anterior, mas corrigiu o problema apenas parcialmente, atingindo um pico de treze solicitações. O estudo descobriu que a escolha do algoritmo depende inteiramente do que o sistema precisa proteger. Se o objetivo é manter os usuários satisfeitos e permitir surtos naturais de atividade, como o recarregamento de uma página com múltiplas chamadas de dados, o balde de tokens é a escolha superior porque equilibra alta aceitação com desempenho constante. Se o objetivo é proteger um sistema de jusante frágil que não pode tolerar nenhum pico, o log de janela deslizante é a melhor opção, apesar de sua menor taxa de aceitação. A pesquisa conclui que não existe uma ferramenta perfeita para todos os trabalhos; em vez disso, os engenheiros devem escolher o método que se alinhe com sua tolerância específica para picos de tráfego e seus recursos de memória disponíveis.
Afogado em artigos na sua área?
Receba digests diários dos artigos mais recentes que correspondam às suas palavras-chave de pesquisa — com resumos técnicos, no seu idioma.