Raté Limiting e Throttling: Os Bastidores de Como os Gateways Sobrevivem à Black Friday e Picos de 10x

Meia-noite de quinta para sexta-feira na semana da Black Friday. O painel do seu e-commerce pisca com um volume de tráfego que você não via desde novembro do ano anterior. O ponteiro do Google Analytics baté 15.000 usuários simultâneos. Os carrinhos estão cheios. Os clientes começam a clicar em 'Finalizar Compra'. E então, o pesadelo se materializa: a tela de checkout congela. Segundos depois, um aviso genérico de 'Erro ao processar pagamento' aparece para milhares de compradores.

Você acabou de perder milhões de reais em exatos três minutos.

O culpado, na esmagadora maioria das vezes, não é a sua plataforma de e-commerce. O gargalo mora na infraestrutura de pagamentos — o gateway, a adquirente ou o banco emissor. Quando o volume de transações salta de um padrão de 500 TPS (Transactions Per Second) para 5.000 TPS em questão de segundos, a física dos servidores e as leis de rede cobram seu preço.

Observamos nos últimos quinze anos a evolução brutal da infraestrutura financeira brasileira. Saímos dos servidores físicos on-premise para arquiteturas cloud-native distribuídas em microsserviços. Mas a matemática continua impiedosa: nenhum sistema suporta um pico de 10x sem mecanismos de defesa rigorosos.

Se você opera um e-commerce de médio ou grande porte, preste atenção aqui. Entender como Pagar.me, Mercado Pago, Vindi, Adyen e outros players gerenciam capacidade (capacity planning) não é apenas uma curiosidade técnica. É a diferença entre bater a meta do ano ou passar o fim de semana estornando pedidos duplicados e respondendo reclamações no Reclame Aqui.

A Anatomia de um Pico de 10x e o Fator Pix

Para entender o caos, precisamos olhar para os milissegundos. Em uma terça-feira comum, uma transação de cartão de crédito leva cerca de 1.5 a 2 segundos para ser resolvida. O gateway recebe a requisição, envia para a adquirente (Cielo, Stone, Rede), que aciona a bandeira (Visa, Mastercard), que por sua vez interroga o banco emissor (Nubank, Itaú, Bradesco).

Quando a Black Friday atinge seu ápice, a latência de cada um desses saltos aumenta. Um banco emissor que respondia em 300 milissegundos passa a responder em 1.500 milissegundos. Esse atraso em cascata faz com que as conexões fiquem abertas por mais tempo no seu gateway. Os recursos de memória e CPU dos servidores começam a esgotar rápidamente.

O Pix colocou uma carga extra de complexidade nessa equação. Diferente do cartão de crédito, que permite processos assíncronos (autorização prévia e captura posterior), o Pix é visceralmente síncrono. O Banco Central reportou em setembro de 2023 um recorde de 168 milhões de transações Pix em um único dia. Na Black Friday, esse volume se concentra em janelas de minutos.

O gateway precisa consultar o DICT (Diretório de Identificadores de Contas Transacionais) do BACEN, gerar o QR Code dinâmico, aguardar o webhook do banco recebedor e notificar o seu e-commerce. Se o Sistema de Pagamentos Instantâneos (SPI) do Banco Central engasgar por dois segundos, o gateway precisa absorver o impacto sem derrubar toda a operação.

Raté Limiting: O Segurança da Balada

A primeira linha de defesa de qualquer infraestrutura de pagamentos é o Raté Limiting (Limitação de Taxa). A analogia mais precisa é o segurança na porta de uma casa noturna superlotada. A casa tem capacidade para 1.000 pessoas. Se chegarem 5.000 ao mesmo tempo, o segurança simplesmente barra a entrada dos excedentes, permitindo que quem está dentro continue respirando (e consumindo).

Na prática técnica, o gateway define um limite estrito de requisições que o seu e-commerce pode fazer por segundo ou por minuto. Por exemplo, 100 requisições por segundo por token de API.

Se você enviar 150 requisições no mesmo segundo, o gateway processará as primeiras 100. Para as 50 restantes, ele devolverá imediatamente um código de erro HTTP: o famoso 429 Too Many Requests.

Isso muda o jogo para o lojista. Receber um erro 429 não significa que a API está fora do ar. Significa que a API está viva, saudável, e protegendo a si mesma. Os gateways modernos útilizam algoritmos específicos para isso, sendo o mais comum o Token Bucket.

Imagine um balde que recebe 100 fichas por segundo. Cada transação que você envia consome uma ficha. Se você enviar 150 transações, as últimas 50 encontrarão o balde vazio e serão rejeitadas. O balde só será reabastecido no segundo seguinte.

Gateways como a Stripe e a Adyen deixam esses limites claros em seus contratos de SLA (Service Level Agreement). No Brasil, players como Iugu e Juno (agora Ebanx) também aplicam limites rígidos. A sua plataforma de e-commerce precisa estar preparada para ler esse erro 429 e aplicar um mecanismo de "Exponential Backoff" — esperar 1 segundo, tentar novamente; se falhar, esperar 2 segundos; depois 4 segundos, antes de avisar o cliente final que houve um problema.

Throttling: A Arte de Enfileirar o Caos

Enquanto o Raté Limiting corta o mal pela raiz rejeitando requisições, o Throttling tem uma abordagem mais diplomática. Ele não barra o cliente imediatamente; ele pede para o cliente esperar na fila.

Usando a mesma analogia da casa noturna: o Throttling é o bartender que, diante de 50 pessoas pedindo bebida ao mesmo tempo, reduz o ritmo de preparo deliberadamente para não errar nenhum pedido e manter a ordem no balcão.

Quando um gateway percebe que a adquirente (por exemplo, a Getnet) está demorando 4 segundos para responder em vez do habitual 1 segundo, ele ativa o throttling. As requisições que chegam do seu e-commerce não recebem um erro 429. Elas são colocadas em uma fila interna (geralmente usando tecnologias como Apache Kafka ou RabbitMQ).

O gateway então começa a drenar essa fila em uma velocidade controlada (algoritmo de Leaky Bucket). O balde tem um furo no fundo que deixa a água vazar a uma taxa constante, não importa quanta água seja jogada em cima.

O resultado? A transação que normalmente levaria 2 segundos vai levar 8 ou 10 segundos. O cliente final vê a rodinha de 'Processando' girar por mais tempo na tela do celular.

Para o varejista, o throttling apresenta um perigo silencioso: os Timeouts. Se o seu e-commerce está configurado para desistir da conexão após 5 segundos, mas o gateway colocou a transação em throttling e levou 8 segundos para processar, temos um desastre. O seu sistema cancela a venda na tela do cliente (HTTP 504 Gateway Timeout), mas 3 segundos depois, o gateway consegue processar junto à adquirente e debita o limite do cartão do cliente.

O cliente fica sem o pedido na loja, mas com a cobrança no aplicativo do Nubank. É a receita perfeita para um chargeback amargo e um cliente perdido para sempre.

Capacity Planning e Engenharia do Caos

Esqueça a ideia de que a nuvem é mágica e tem recursos infinitos. O auto-scaling da AWS, Google Cloud ou Azure leva tempo. Subir novos contêineres e alocar novos nós de banco de dados pode demorar de 2 a 5 minutos. Em uma Black Friday, 5 minutos de lentidão representam milhares de transações perdidas.

Por isso, os grandes gateways brasileiros não confiam apenas no auto-scaling reativo. Eles práticam o que chamamos de Pre-warming (pré-aquecimento). Semanas antes da Black Friday, engenheiros de SRE (Site Reliability Engineering) de empresas como Stone e Mercado Pago entram em contato com os maiores varejistas da base para entender a projeção de vendas.

Eles superprovisionam a infraestrutura deliberadamente, dobrando ou triplicando a quantidade de servidores ativos 24 horas antes do evento. Pagam caro pela infraestrutura ociosa temporária para garantir que, quando o relógio bater 00h00, a capacidade de processamento já esteja disponível.

Além disso, adotam a Engenharia do Caos (Chaos Engineering). Inspirados pela Netflix, os times de tecnologia simulam falhas catastróficas em produção durante a madrugada nos meses anteriores. Eles derrubam bancos de dados propositalmente, simulam latência de 10 segundos na comúnicação com a bandeira Visa, e verificam se os sistemas de fallback entram em ação como esperado.

Roteamento Dinâmico e Circuit Breakers: O Plano B

Quando o Raté Limiting e o Throttling não são suficientes porque uma adquirente inteira saiu do ar (algo que infelizmente ainda acontece no ecossistema brasileiro), entra em cena o herói da alta disponibilidade: o Roteamento Dinâmico.

A regra é clara: não coloque todos os ovos na mesma cesta. Gateways robustos operam com multi-adquirência. Se o seu e-commerce envia uma transação para o gateway e ele tenta processar pela Rede, mas percebe que a Rede está retornando erros 503 (Service Unavailable) ou estourando o tempo limite, um mecanismo chamado Circuit Breaker é ativado.

O Circuit Breaker funciona exatamente como o disjuntor de energia da sua casa. Se há uma sobrecarga, ele desarma. O gateway para de enviar requisições para a Rede instantaneamente, protegendo o sistema de ficar travado esperando respostas que não virão.

No mesmo milissegundo, a inteligência de roteamento redireciona aquela transação específica para a Cielo ou para a Stone. O cliente final nem percebe que houve uma falha na primeira tentativa. A transação é aprovada no Plano B.

O Manual de Sobrevivência do Lojista

A infraestrutura financeira faz a parte dela, mas o seu e-commerce tem obrigações técnicas inegociáveis. Se você quer sobreviver aos picos de 10x, exija que sua equipe de tecnologia implemente três pilares fundamentais hoje mesmo.

Primeiro: Chaves de Idempotência. Toda requisição de pagamento enviada ao gateway deve conter um ID único (Idempotency Key). Se ocorrer um timeout e o seu sistema tentar enviar a transação novamente, o gateway reconhecerá a chave e saberá que se trata de uma retentativa, não de uma nova compra. Isso elimina 100% o risco de cobranças duplicadas no cartão do cliente.

Segundo: Alinhamento de Timeouts. Revise a configuração de tempo limite da sua plataforma. Se o gateway tem um SLA de resposta de até 15 segundos em momentos de estrêsse, o seu e-commerce não pode abortar a conexão em 10 segundos. O cliente aguenta olhar para a tela de carregamento por 15 segundos se a recompensa for garantir a TV com 50% de desconto.

Terceiro: Dependência de Webhooks. Não confie apenas na resposta síncrona da tela de checkout. Configure seu sistema para processar os pedidos com base nas notificações assíncronas (webhooks) que o gateway envia nos bastidores. Muitas vezes, a tela do cliente dá erro de conexão, mas o webhook chega dois segundos depois confirmando o pagamento. Se o seu sistema lê o webhook, ele atualiza o status do pedido para 'Pago' e envia um e-mail tranquilizando o comprador.

O mercado financeiro brasileiro atingiu um nível de maturidade invejável. A resiliência demonstrada pelo ecossistema Pix é um case de estudo global. Contudo, a física da computação dita que recursos são finitos. Entender as regras de Raté Limiting e Throttling do seu provedor de pagamentos não é um preciosismo técnico — é o alicerce estratégico que garante que o faturamento projetado na planilha de marketing se torne dinheiro real na conta bancária da sua empresa.