API Gateway a sério: o que muda quando você opera para milhões de requests por dia
Existe uma diferença qualitativa entre montar um API gateway para um side project e operar um para uma fintech global. Aqui está o que aprendi operando no segundo cenário.
O primeiro API gateway que eu configurei profissionalmente levou três horas. Funcionou na primeira vez que testei. Fiquei satisfeito.
O trabalho que faço agora com gateway é diferente em natureza — não só em escala. Não é mais "funciona quando eu testo". É "não pode parar de funcionar, nunca, para ninguém".
A diferença não começa no código. Começa na mentalidade.
Quando você opera infraestrutura que processa pagamentos para milhões de pessoas, "funciona" tem uma definição diferente. Funciona significa: funciona quando há dez vezes o tráfego normal. Funciona quando um datacenter regional fica indisponível. Funciona quando a API upstream que você depende começa a retornar 500 em 3% das requisições. Funciona quando um certificado TLS expira no sábado às 3h da manhã.
Esse tipo de "funciona" exige pensar em falha como condição normal, não como exceção.
Em produção a sério, a configuração do gateway não é o trabalho. O trabalho é o ciclo que vem depois: observar o que está acontecendo, entender os padrões, ajustar a configuração, medir o impacto, repetir. Um gateway bem configurado tem métricas em cada ponto relevante — latência por rota, taxa de erro por cliente, uso de quota, cache hit rate, latência upstream vs. total.
Sem essas métricas, você está voando cego. Com elas, você começa a entender a personalidade do tráfego — quando ele aumenta, de onde ele vem, quais endpoints são lentos por natureza vs. quais estão lentos porque algo está errado.
Rate limiting parece simples até você tentar fazer direito. A questão não é só "quantas requisições por minuto" — é por quem, medido como, com que comportamento quando o limite é atingido, com exceções para quais casos, e como você evita que um cliente mal-comportado degrade a experiência dos outros.
Num ambiente de alta escala, você também precisa pensar em distributed rate limiting — porque seu gateway não é um processo, é uma frota. Contar requisições em memória local não funciona quando você tem dezenas de instâncias recebendo tráfego em paralelo. Você precisa de um estado compartilhado, e esse estado compartilhado tem latência, e essa latência tem implicações para o throughput.
O que mais mudou na minha forma de pensar foi a relação com o downstream. Um gateway não existe sozinho — ele é intermediário entre clientes e APIs. Quando a API upstream degrada, o gateway decide o que acontece: retorna o erro para o cliente, implementa circuit breaker, serve resposta em cache, faz fallback para outra instância.
Essas decisões parecem técnicas mas são produto: elas determinam a experiência do desenvolvedor que consome sua API. Um gateway bem desenhado protege os consumidores de falhas dos produtores. Um mal desenhado propaga cada problema upstream diretamente para baixo.
Compliance mudou tudo. Quando você opera em ambiente financeiro regulado, cada requisição que passa pelo gateway precisa ser auditável. Quem fez, quando, com que payload, qual foi a resposta. Isso parece simples mas tem implicações sérias de performance, armazenamento e privacidade — você não pode logar tudo ingenuamente em ambiente com PII.
Aprendi mais sobre segurança de dados operando um gateway em ambiente financeiro do que em qualquer curso ou certificação.
O que eu diria para alguém que está começando com API gateway: configure um, coloque em produção com tráfego real, e observe o que acontece por 30 dias. Você vai aprender mais nesse mês do que em qualquer tutorial. O gateway vai revelar os padrões de uso que você não imaginava, as falhas que você não antecipou, e as decisões de design que você vai querer refazer.
Infraestrutura de plataforma se aprende operando, não lendo sobre operar.
Essa semana: se você usa um API gateway no trabalho, abre o painel de métricas e passa 15 minutos entendendo o que está sendo medido. Qual é a latência p99 do endpoint mais crítico? Qual cliente está gerando mais tráfego? Existe algum erro que aparece repetidamente que ninguém está investigando? Observabilidade começa com a decisão de olhar.