Leaky Bucket vs Token Bucket: Guia Prático de Limitação de Taxa em APIs

O Desafio do Tráfego Imprevisível em APIs

Imagine que você gerencia a bilheteria de um grande show. Milhares de pessoas chegam ao mesmo tempo na entrada, criando uma fila gigante e tumultuada. Se os funcionários deixarem todo mundo passar de uma vez, as rocatrizas quebram e a segurança fica comprometida. Para resolver isso, os organizadores criam barreiras físicas que controlam o fluxo, deixando passar apenas um número seguro de pessoas por minuto. No mundo do desenvolvimento de software, esse problema é constante e acontece quando aplicações recebem milhares de acessos simultâneos.

Quando uma API (interface de programação de aplicações, o canal digital que permite a conversas entre sistemas) sofre um pico repentino de tráfego, seus servidores podem simplesmente parar de responder por falta de memória ou poder de processamento. Para evitar que isso aconteça, engenheiros utilizam técnicas de controle de vazão e limitação de taxa (ou rate limiting, em inglês). Essas técnicas funcionam como as barreiras da bilheteria, decidindo quem entra imediatamente, quem vai para uma fila de espera e quem recebe uma mensagem educada de que o sistema está lotado no momento.

Existem várias formas de resolver esse problema, mas duas delas se destacam pela eficiência e popularidade na indústria: o Leaky Bucket (balde furado) e o Token Bucket (balde de fichas). Cada um possui uma filosofia distinta sobre como lidar com o tempo e com os picos de acesso. Conhecer a fundo o funcionamento, as vantagens e os trade-offs (as perdas e ganhos em uma decisão de design) dessas duas estratégias é fundamental para projetar sistemas resilientes e capazes de suportar falhas sem perder dados.

Como Funciona o Algoritmo Leaky Bucket na Prática

O conceito do Leaky Bucket é visualmente muito simples. Pense em um balde que possui um pequeno furo no fundo. Não importa com que velocidade você jogue água dentro desse balde — seja despejando um copo devagar ou virando um balde inteiro de uma vez —, a água de dentro sempre vai escapar pelo furo de baixo em um ritmo constante, gota a gota. Na computação, a água representa as requisições que chegam dos usuários, o balde é a fila de espera na memória do servidor e o furo é a taxa fixa de processamento da aplicação.

Na prática, quando chega uma nova requisição, ela é colocada no balde. Se o balde estiver cheio — ou seja, se a fila de espera atingir seu limite máximo —, as novas requisições que chegarem transbordam e são rejeitadas imediatamente com um erro HTTP 429 (muitas solicitações). Enquanto isso, o sistema retira requisições do balde para processamento a uma velocidade constante e imutável. Isso significa que, por mais caótico que seja o tráfego externo, o servidor interno trabalhará sempre em um ritmo calmo e previsível.

Essa característica torna o Leaky Bucket excelente para cenários onde o destino final das requisições possui uma capacidade de processamento rígida e não tolera nenhum tipo de oscilação. Por exemplo, ao enviar dados para uma API de terceiros que possui um contrato estrito de limite de envio de mensagens por segundo, o Leaky Bucket garante que sua aplicação nunca viole esse limite, pois a saída é rigorosamente cadenciada. O lado negativo é que ele é inflexível: se um usuário legítimo precisar enviar uma rajada rápida de dez requisições em um microssegundo, nove delas serão atrasadas ou descartadas, mesmo que o servidor tenha folga momentânea.

Entendendo o Mecanismo do Token Bucket

Diferente do balde furado, o Token Bucket (balde de fichas) foi desenhado para abraçar a imprevisibilidade do comportamento humano na internet. Nesse modelo, o balde não armazena as requisições em si, mas sim fichas (tokens) que dão o direito de fazer uma requisição. Um processo em segundo plano adiciona novas fichas ao balde a uma taxa constante, digamos, dez fichas por segundo. O balde possui uma capacidade máxima; se estiver cheio, novas fichas geradas são simplesmente descartadas.

Quando um usuário faz uma requisição para a API, o sistema verifica se há fichas disponíveis no balde. Se houver, uma ficha é consumida e a requisição é processada imediatamente. Se o balde estiver vazio porque o usuário gastou todas as fichas de uma vez, a requisição é rejeitada ou colocada em uma fila de espera. Na prática, isso significa que se um usuário ficar ocioso por alguns minutos, o balde encherá até a capacidade máxima. Quando ele voltar, poderá disparar várias requisições de uma só vez (uma rajada ou burst), consumindo todo o estoque acumulado instantaneamente.

Essa flexibilidade faz do Token Bucket a escolha mais popular para APIs públicas, portais de comércio eletrônico e redes sociais. Os usuários adoram essa abordagem porque a navegação parece fluida e rápida, sem bloqueios desnecessários durante ações normais de cliques múltiplos. Para os engenheiros, o desafio reside em dimensionar corretamente a capacidade máxima do balde e a velocidade de reposição das fichas, garantindo que picos legítimos sejam atendidos sem que a infraestrutura sofra quedas de performance.

Comparação Direta: Trade-offs entre Leaky Bucket e Token Bucket

Para escolher o algoritmo ideal para o seu projeto, precisamos colocar ambos lado a lado e analisar seus comportamentos sob diferentes condições de estresse. O quadro a seguir resume as principais diferenças estruturais e operacionais entre as duas abordagens:

Em termos de consumo de recursos computacionais, o Token Bucket costuma ser mais leve para aplicações web de alta escala. Como ele não precisa guardar cada requisição em uma fila física, mas apenas atualizar um número inteiro (a quantidade de fichas restantes), o custo de processamento por requisição é mínimo. O Leaky Bucket, por sua vez, exige estruturas de dados em fila (como arrays ou listas encadeadas) que consomem mais memória RAM, especialmente quando há um grande volume de conexões aguardando liberação.

Outro ponto crítico é a experiência do usuário final. Se você está construindo uma aplicação de chat ou um painel financeiro em tempo real, o Token Bucket oferece uma sensação de velocidade superior, pois permite que pacotes de dados curtos passem sem atrasos artificiais. Por outro lado, se você está integrando sistemas legados frágeis que travam com mais de cinquenta requisições por segundo, o Leaky Bucket atua como um escudo protetor indispensável, nivelando o fluxo de entrada e impedindo qualquer sobrecarga catastrófica no banco de dados.

Implementando Controle de Taxa em Ambientes Distribuídos

Na arquitetura de software moderna, raramente rodamos uma aplicação em apenas um servidor. Sistemas escaláveis utilizam múltiplos nós (instâncias rodando em paralelo) balanceados por um roteador central. Isso cria um problema interessante para a limitação de taxa: como controlar o balde de fichas ou o balde furado se as requisições de um mesmo usuário chegam em servidores diferentes? Se cada servidor mantiver seu próprio controle isolado, o usuário poderá burlar o limite simplesmente redirecionando suas chamadas entre as instâncias.

A solução padrão de mercado para esse cenário é utilizar um banco de dados em memória de alta performance, sendo o Redis a escolha mais comum. O Redis permite armazenar o estado das fichas de cada usuário de forma centralizada e acessível em milissegundos por qualquer servidor da frota. Além disso, ele oferece suporte a operações atômicas e scripts executados diretamente no servidor de banco de dados (usando a linguagem Lua), garantindo que duas requisições simultâneas não consigam modificar o mesmo balde ao mesmo tempo de forma incorreta.

Abaixo temos um exemplo conceitual em código Python demonstrando a lógica de um Token Bucket utilizando uma estrutura simples em memória, que pode ser facilmente adaptada para consultar o Redis em um ambiente distribuído:

import time

class TokenBucket:
    def __init__(self, capacity: int, refill_rate: float):
        self.capacity = capacity
        self.tokens = float(capacity)
        self.refill_rate = refill_rate
        self.last_refill = time.time()

    def _refill(self):
        now = time.time()
        elapsed = now - self.last_refill
        self.last_refill = now
        # Adiciona fichas com base no tempo decorrido
        self.tokens = min(self.capacity, self.tokens + elapsed * self.refill_rate)

    def consume(self, tokens: int = 1) -> bool:
        self._refill()
        if self.tokens >= tokens:
            self.tokens -= tokens
            return True
        return False

# Exemplo de uso
bucket = TokenBucket(capacity=10, refill_rate=2.0) # 10 fichas max, repõe 2 por segundo
if bucket.consume():
    print('Requisição permitida!')
else:
    print('Muitas solicitações. Tente novamente mais tarde.')

Nesse código, a função _refill calcula exatamente quantas fichas devem ser devolvidas ao balde com base no tempo que passou desde a última verificação. Essa abordagem é conhecida como cálculo baseado em tempo decorrido (lazy refill), evitando a necessidade de manter processos em segundo plano rodando o tempo todo para encher o balde.

Considerações Finais e Melhores Práticas Operacionais

A escolha entre Leaky Bucket e Token Bucket não deve ser tratada como uma decisão puramente técnica sem contexto de negócio. Ela reflete a promessa de serviço que sua API faz aos clientes. Enquanto o Token Bucket prioriza a agilidade e a tolerância a rajadas de uso natural, o Leaky Bucket prioriza a previsibilidade absoluta e a proteção de recursos computacionais sensíveis contra picos destrutivos de tráfego.

Ao implementar essas estratégias em produção, lembre-se sempre de comunicar claramente os limites aos consumidores da sua API através de cabeçalhos HTTP padronizados, como X-RateLimit-Limit, X-RateLimit-Remaining e X-RateLimit-Reset. Isso permite que os desenvolvedores que consomem sua interface ajustem seus próprios softwares para respeitar as regras, evitando bloqueios frustrantes e melhorando a confiabilidade de todo o ecossistema tecnológico.