O essencial
Um limitador de taxa distribuída implementado corretamente (contagem atômica, cache de fallback local) normalmente adiciona menos de um milissegundo por solicitação, de acordo com diversas fontes especializadas. O gateway Aurabase segue exatamente este padrão: a caixa governor para anti-DoS local, um script Lua Redis atômico para contagem distribuída entre instâncias, um cache moka substituto se o Redis não estiver disponível. O circuito do disjuntor reduz a latência percebida no caso de uma falha, em vez de adicioná-la – ele provoca um curto-circuito na espera por um tempo limite completo. Nenhum número de latência do Aurabase foi publicado até o momento: aqui está o porquê e como o mecanismo realmente funciona.
Falha anti-DoS e anti-cascading, dois problemas distintos
A limitação de taxa protege seu back-end de tráfego excessivo, legítimo ou não — ela responde à pergunta “este chamador tem o direito de enviar esta solicitação agora?” ". O disjuntor protege seu back-end de um serviço já downstream - ele responde a “este serviço já deixou de responder, deveríamos tentar?” ". Confundi-los leva ao subdimensionamento de um ou de outro.
No gateway Aurabase, ambos residem na mesma pilha de middleware, mas em andares diferentes: a limitação da taxa de IP é executada antes da autenticação (puro anti-DoS, sem consultas SQL de cobrança emitidas para tráfego não autenticado), enquanto o disjuntor protege chamadas de saída para serviços internos ou provedores LLM.
O custo depende inteiramente da implementação, não do princípio
De acordo com Tyk e os guias do ecossistema APISIX, a contagem distribuída bem projetada no Redis (operações atômicas, script Lua, TTL nativo) normalmente adiciona 1-3 ms de latência, com impacto p99 inferior a um milissegundo nos casos mais otimizados. Por outro lado, o Zuplo documenta que um limitador de taxa centralizado mal colocado pode adicionar dezenas de milissegundos a cada solicitação – essa discrepância se reflete diretamente no seu p99.
Esses intervalos vêm de guias técnicos públicos (ecossistema Tyk, Zuplo, Apache APISIX), e não de um protocolo de medição comum. Indicam uma ordem de grandeza e um princípio arquitectónico – contagem atómica e local em vez de síncrona e centralizada – e não um número a ser reproduzido como acontece numa infra-estrutura diferente.
Como a limitação de taxa realmente funciona no aura-gateway
O gateway Aurabase usa a caixa governor (algoritmo de token bucket) como um limitador de fallback local, juntamente com contagem distribuída via Redis para compartilhar o estado entre várias instâncias do gateway. A contagem distribuída passa por um script Lua executado atomicamente no lado do Redis (INCRBY + EXPIRE em uma única operação de rede), não por meio de uma viagem de ida e volta de leitura e gravação que introduziria uma janela de simultaneidade.
Se o Redis ficar indisponível, o gateway mudará automaticamente para o limitador local governor, com um cache moka (máximo de 1.000.000 entradas, expiração em 300 segundos de inatividade) para evitar a recriação de um limitador em cada solicitação. Esse substituto é observável: cada alternância incrementa um contador Prometheus dedicado, para que a equipe saiba quando o limite efetivo se torna N instâncias × limite novamente (caso contrário, degradação silenciosa do isolamento entre instâncias).
O gateway distingue a limitação de taxa anti-DoS por IP (antes da autenticação) da limitação de taxa por projeto/chave de API/cota de usuário (após a autenticação, com declarações JWT disponíveis) — dois middlewares separados na pilha, cada um com sua própria granularidade.
O disjuntor: três estados, uma janela deslizante
O circuito do disjuntor Aurabase (aura_core::circuit_breaker, compartilhado entre o gateway e aura-ai para fallback entre provedores LLM) segue três estados clássicos - Closed, Open, HalfOpen - com uma contagem de falhas em uma janela de tempo deslizante em vez de um contador que nunca é zerado.
Um detalhe de implementação que importa na produção: mudar para HalfOpen permite apenas uma solicitação de investigação por vez (anti-rebanho trovejante) — sem essa proteção, todas as solicitações pendentes correriam simultaneamente para o serviço que acabou de reabrir, recriando imediatamente a falha que estávamos tentando evitar.
Onde esses middlewares são executados no gateway
A pilha de middleware do gateway Aurabase segue uma ordem precisa, verificada no código: identificador de solicitação → log de acesso → limitação de taxa por IP → autenticação → limitação de taxa por ator/cota → disjuntor → proxy para o serviço de destino. Cada estágio rejeita o tráfego indesejado o mais cedo possível, antes de incorrer em um custo de processamento mais alto no downstream.
Leia o artigo completo: plano de dados vs plano de gerenciamento no gateway Aurabase
Por que nenhum número da Aurabase é publicado aqui
A implementação é verificada linha por linha no código-fonte do gateway. Mas ainda não foi executado e publicado nenhum protocolo de medição reproduzível nesta infraestrutura específica – publicar um número não medido seria repetir o erro dos números de marketing sem fontes que nos recusamos a reproduzir. Consulte nossa metodologia de benchmark completa para saber o que precisamos antes de divulgar um valor de desempenho.