Aplicações Sênior: Motor de Rate Limiting com Redis e Lua

Código, Debugging, desenvolvimento web, Guia Prático, inteligência artificial, PHP, PHPUnit, produtividade, Programação, Refatoração, Regex, Testes Unitários

Proteger a sua API REST do WordPress contra abusos não é uma opção, é um requisito fundamental de segurança e performance.
Muitos desenvolvedores confiam em firewalls de borda como o Cloudflare para essa tarefa.
No entanto, existem cenários onde a lógica de limitação de taxa (Rate Limiting) precisa estar profundamente acoplada às regras de negócio da sua aplicação.
Por exemplo, você pode querer permitir que usuários gratuitos façam dez requisições por minuto, enquanto clientes de planos premium podem fazer mil.
Nesta masterclass, vamos construir um motor de Rate Limiting baseado no algoritmo Token Bucket.
Utilizaremos o Redis não apenas como armazenamento, mas como motor de processamento usando scripts Lua.
Isso garante a atomicidade das operações e evita condições de corrida (race conditions) em ambientes de alta concorrência.
Vamos elevar o nível da sua arquitetura backend.

Compreendendo o Algoritmo Token Bucket

O algoritmo Token Bucket é o padrão da indústria, utilizado por gigantes como AWS e Stripe.
Imagine um balde que tem uma capacidade máxima de “tokens” (fichas).
A cada requisição que um usuário faz, ele retira uma ficha desse balde.
Simultaneamente, um processo em segundo plano reabastece o balde a uma taxa constante, até o seu limite máximo.
Se o usuário tentar fazer uma requisição e o balde estiver vazio, a API retorna o status HTTP 429 (Too Many Requests).
A grande vantagem deste algoritmo é que ele permite pequenos picos temporários de tráfego (bursts), desde que o balde tenha capacidade.
Implementar isso no banco de dados MySQL seria um desastre de performance, pois geraríamos milhares de operações de leitura e escrita por segundo.
É exatamente aqui que o Redis brilha.

Por que usar Scripts Lua no Redis?

Se tentarmos implementar a lógica do Token Bucket apenas com comandos PHP e Redis padrão, enfrentaremos um grave problema de concorrência.
O PHP precisaria ler a quantidade atual de tokens, calcular o reabastecimento, subtrair um token e salvar o novo valor.
Entre a leitura e a escrita, outra requisição paralela poderia ler o valor antigo, causando uma falha na contagem (race condition).
O Redis resolve isso permitindo a execução de scripts escritos na linguagem Lua diretamente no seu núcleo.
A execução de um script Lua no Redis é totalmente atômica.
Isso significa que nenhum outro comando Redis pode ser executado enquanto o script não terminar.
Esta é a verdadeira engenharia de software sênior aplicada à resolução de problemas complexos de infraestrutura. 

// Script Lua para Token Bucket atômico no Redis
$lua_script = "
local tokens_key = KEYS[1]
local timestamp_key = KEYS[2]
local rate = tonumber(ARGV[1])
local capacity = tonumber(ARGV[2])
local now = tonumber(ARGV[3])
local requested = tonumber(ARGV[4])

local fill_time = capacity / rate
local ttl = math.floor(fill_time * 2)

local last_tokens = tonumber(redis.call('get', tokens_key))
if last_tokens == nil then
  last_tokens = capacity
end

local last_refreshed = tonumber(redis.call('get', timestamp_key))
if last_refreshed == nil then
  last_refreshed = 0
end

local delta = math.max(0, now - last_refreshed)
local filled_tokens = math.min(capacity, last_tokens + (delta * rate))
local allowed = filled_tokens >= requested
local new_tokens = filled_tokens

if allowed then
  new_tokens = filled_tokens - requested
end

redis.call('setex', tokens_key, ttl, new_tokens)
redis.call('setex', timestamp_key, ttl, now)

return { allowed and 1 or 0, new_tokens }
";

A Integração do Motor no WordPress

Com a fundação atômica estabelecida, precisamos conectar essa lógica ao ciclo de vida da REST API do WordPress.
Faremos isso utilizando o hook rest_api_init e interceptando as requisições através do filtro rest_pre_dispatch.
Este filtro é disparado antes mesmo do WordPress tentar localizar o endpoint correspondente.
Se o limite for excedido, nós cortamos a execução imediatamente e devolvemos a resposta bloqueada.
Isto poupa recursos preciosos de CPU e memória do servidor, pois evitamos o carregamento de consultas pesadas do banco de dados relacional.
Nesta camada, criaremos uma classe PHP encapsulada baseada no princípio de Responsabilidade Única (SOLID). 

// Classe Service Layer para encapsular o Rate Limiter
class ApiRateLimiterService {
    private Redis $redis;
    
    public function __construct() {
        $this->redis = new Redis();
        $this->redis->connect('127.0.0.1', 6379);
    }
    
    public function checkLimit(string $ip_address): bool {
        global $lua_script; // O script Lua definido anteriormente
        
        $tokens_key = "rate_limit:tokens:" . $ip_address;
        $timestamp_key = "rate_limit:timestamp:" . $ip_address;
        $rate = 1; // 1 token por segundo
        $capacity = 10; // Capacidade máxima de 10 tokens no balde
        $now = time();
        $requested = 1; // Custo desta requisição
        
        $result = $this->redis->eval(
            $lua_script, 
            [$tokens_key, $timestamp_key, $rate, $capacity, $now, $requested], 
            2
        );
        
        return (bool) $result[0];
    }
}

Injeção de Cabeçalhos HTTP e UX do Desenvolvedor

Um sistema profissional de Rate Limiting não se limita a bloquear requisições.
Ele deve informar o cliente da API sobre o estado atual dos seus limites.
Isso é feito através da injeção de cabeçalhos HTTP específicos na resposta.
Os cabeçalhos padrão da indústria incluem X-RateLimit-Limit, X-RateLimit-Remaining e Retry-After.
Essas informações permitem que os desenvolvedores que consomem sua API programem seus próprios algoritmos de retentativa de forma graciosa.
No WordPress, podemos utilizar o objeto WP_REST_Response para anexar esses dados diretamente na saída.
É a diferença entre uma API hostil e uma API construída por especialistas com foco na experiência do desenvolvedor (DX). 

// Interceptando a requisição no WordPress
add_filter('rest_pre_dispatch', function($result, $server, $request) {
    $ip = $_SERVER['REMOTE_ADDR'];
    $limiter = new ApiRateLimiterService();
    
    if (!$limiter->checkLimit($ip)) {
        $response = new WP_Error(
            'rest_too_many_requests',
            'Limite de requisições excedido. Tente novamente mais tarde.',
            array('status' => 429)
        );
        
        // Adicionando cabeçalho amigável
        header('Retry-After: 60');
        return $response;
    }
    return $result;
}, 10, 3);

Testes de Carga e Benchmarks Teóricos

A arquitetura proposta aqui é capaz de suportar tens de milhares de requisições por segundo em um servidor Redis modesto.
Como a operação Lua ocorre em memória RAM e em um único thread bloqueante, a latência adicionada por verificação é inferior a um milissegundo.
Isso é virtualmente imperceptível para o cliente e infinitamente mais rápido do que uma consulta equivalente no MySQL usando a tabela wp_options ou wp_postmeta.
Recomendamos o uso de ferramentas como o Apache JMeter ou o k6 (da Grafana) para simular picos de tráfego e validar a configuração.
Ajustar a capacidade do balde (burst) e a taxa de reabastecimento é um processo iterativo.
Você deve monitorar o log de erros 429 para entender se os limites impostos não estão prejudicando o uso legítimo da plataforma.

Considerações de Segurança e Escalabilidade

Para sistemas distribuídos em múltiplos servidores (Load Balancers), o uso do Redis centralizado garante que o limite seja global, e não local por máquina.
No entanto, depender do endereço IP para identificação pode ser falho devido a usuários atrás de NAT corporativo (CGNAT) ou redes móveis compartilhadas.
Para APIs autenticadas, o limite deve ser vinculado ao ID do Usuário (via JWT ou Application Passwords) em vez do IP.
Você pode facilmente adaptar a chave do Redis no código acima para usar $user_id.
A construção de defesas em camadas é o que protege aplicações corporativas contra ataques de negação de serviço (DDoS) a nível de aplicação (Layer 7).

Conclusão da Masterclass

O desenvolvimento avançado em PHP e WordPress exige que olhemos além do painel de administração.
A introdução de tecnologias como Redis e Lua transforma o WordPress em um framework de aplicação verdadeiramente corporativo e escalável.
Os conceitos de atomicidade, controle de fluxo e Service Layers apresentados aqui são transferíveis para qualquer outra linguagem moderna.
A Clean Architecture não é apenas teoria; ela se manifesta na clareza em que as regras de negócio são isoladas da infraestrutura de rede.
Espero que esta aplicação eleve o padrão dos seus projetos.
Continue investindo tempo no aprofundamento técnico, pois a verdadeira maestria está nos detalhes da execução.

Posts relacionados

Rolar para cima