Rate Limiting Distribuído em Serverless: Redis Cluster e Scripts Lua

O Desafio de Controlar Tráfego em Arquiteturas Sem Servidor

Quando desenvolvemos aplicações modernas baseadas em nuvem, costumamos usar arquiteturas sem servidor, onde funções minúsculas sobem e descem conforme a demanda de acessos. Na prática, isso significa que podemos ir de zero a dezenas de milhares de requisições em segundos. O lado bom é a economia e a elasticidade infinita. O lado desafiador é que proteger suas APIs contra abusos ou ataques de negação de serviço torna-se extremamente complexo. Sem um controle firme, uma única função automatizada pode esgotar o banco de dados principal em poucos segundos.

O controle de tráfego, conhecido na engenharia como rate limiting, serve exatamente para impor limites na quantidade de vezes que um usuário ou sistema pode chamar uma rota em um intervalo específico. Em servidores tradicionais de longa duração, manter esse controle na memória é relativamente simples. Porém, em ambientes sem servidor, as instâncias nascem e morrem constantemente. Cada função isolada não tem conhecimento do que as outras instâncias estão fazendo, criando um cenário caótico onde contadores locais falham miseravelmente.

A Escolha do Redis Cluster para Escalabilidade Horizontal

Para resolver o problema da falta de memória compartilhada entre as funções, precisamos de um banco de dados em memória ultrarrápido, e o Redis é a escolha padrão da indústria. Ele armazena chaves e valores diretamente na memória RAM, permitindo respostas na casa dos microssegundos. No entanto, um único servidor Redis tem limites físicos de memória e processamento. É aí que entra o Redis Cluster, uma topologia que distribui os dados automaticamente entre vários nós interligados.

Na prática, o cluster divide o espaço total de chaves em blocos chamados de slots, espalhando essas fatias por diferentes máquinas. Quando uma função sem servidor precisa verificar se um cliente excedeu o limite de requisições, ela consulta o cluster. Se o nó consultado não possuir aquele dado específico, ele redireciona a requisição de forma transparente. Essa divisão de carga permite que o sistema suporte picos massivos de tráfego sem que nenhum servidor isolado vire um gargalo de desempenho.

Garantindo Consistência com Scripts Lua

Um dos maiores perigos ao usar bancos de dados distribuídos para contar requisições é a famosa condição de corrida. Imagine que duas instâncias sem servidor recebam uma requisição do mesmo usuário exatamente ao mesmo tempo. Ambas leem o contador atual, digamos que o valor seja cinco, somam um e escrevem de volta o número seis. O limite de seis deveria bloquear a segunda requisição, mas como leram juntas, ambas passam. Esse erro sutil permite que usuários maliciosos ultrapassem os limites estabelecidos.

Para eliminar esse problema de concorrência, utilizamos scripts escritos em Lua, uma linguagem de programação leve que pode ser executada diretamente dentro do próprio Redis. Quando enviamos um script Lua para o Redis, ele executa o bloco de código de forma completamente atômica. Isso significa que nenhuma outra operação consegue ler ou alterar os dados enquanto o script estiver rodando. Na prática, a verificação do limite, a soma do contador e a definição do tempo de expiração acontecem em um único bloco indivisível, garantindo precisão matemática absoluta mesmo sob concorrência extrema.

Implementando a Lógica de Janela Deslizante

Existem várias estratégias para calcular limites de tráfego, sendo a janela fixa a mais simples e a janela deslizante a mais precisa. Na janela fixa, reiniciamos o contador a cada minuto cravado, o que gera um problema conhecido como pico de borda: um usuário pode gastar todo o seu limite nos últimos segundos de um minuto e gastar tudo de novo logo no início do minuto seguinte, dobrando o volume permitido no intervalo de um segundo.

Para evitar essa falha, aplicamos o algoritmo de janela deslizante utilizando estruturas de dados avançadas do Redis, como conjuntos ordenados. O script Lua armazena o registro de tempo exato de cada requisição do usuário. Quando uma nova chamada chega, o script remove registros antigos que ficaram fora da janela de tempo atual e conta quantos elementos sobraram. Se a quantidade estiver abaixo do limite, o carimbo de tempo atual é adicionado. Essa precisão cirúrgica protege seus serviços contra abusos sofisticados sem prejudicar usuários legítimos.

Tratamento de Falhas e Tolerância a Quedas

Sistemas distribuídos convivem diariamente com falhas de rede, lentidões e quedas temporárias de nós. Se o seu mecanismo de controle de tráfego falhar e derrubar a aplicação inteira junto, a solução se torna pior do que o problema. Por isso, a arquitetura precisa prever políticas de tolerância a falhas. Se o Redis Cluster ficar indisponível momentaneamente devido a uma falha de rede na nuvem, a função sem servidor não deve quebrar a requisição do usuário final.

Na prática, implementamos um mecanismo de proteção conhecido como falha aberta controlada. O código da função envolve a chamada ao Redis em um bloco de tratamento de exceções com um tempo limite estrito de resposta. Se o Redis demorar mais do que cinquenta milissegundos para responder, a aplicação assume que há um problema na infraestrutura de cache e permite temporariamente a passagem da requisição. Essa decisão prioriza a disponibilidade do negócio, aceitando um risco controlado de abuso de tráfego por alguns instantes em troca de manter o sistema online.

Considerações Finais sobre Arquiteturas de Alta Resiliência

Construir um sistema de controle de tráfego distribuído exige equilibrar velocidade, precisão e resiliência operacional. O uso conjunto de funções sem servidor, Redis Cluster e scripts Lua representa uma das abordagens mais robustas disponíveis na engenharia de software moderna. Essa combinação garante que mesmo sob ataques coordenados ou picos repentinos de acesso, sua infraestrutura continue estável e previsível.

O segredo do sucesso reside em compreender os limites de cada componente e projetar o código considerando cenários de falha. Ao adotar scripts atômicos e janelas deslizantes bem calibradas, você protege seus recursos internos sem sacrificar a experiência do usuário final, pavimentando o caminho para um crescimento sustentável e seguro na nuvem.