Meça os limites de taxa da API do broker antes dos picos

Uma resposta 429 não é uma estratégia de limite de taxa. É uma evidência de que um cliente já atingiu um limite, e a resposta, por si só, raramente informa à equipe de operações se a causa foi um pico, uma conta ruidosa, um loop de tentativas ou um problema de capacidade que afeta todo o fornecedor. A pergunta útil é quanta demanda está se aproximando desse limite, com que rapidez ela pode ser reduzida e quais fluxos de trading precisam continuar funcionando.

As APIs de brokers costumam aplicar limites em várias camadas: por credencial, conta, endereço IP, endpoint ou conexão simultânea. Um limite pode usar uma janela móvel, um token bucket ou um intervalo fixo.

Uma faixa inicial de planejamento para APIs de brokers e fornecedores pode ser de 5 a 50 requisições por segundo por credencial, com limites menores em endpoints selecionados, mas a política efetiva depende de cada provedor e pode mudar. Trate as cotas publicadas como restrições a serem testadas, não como garantia de capacidade.

Saiba qual limite está medindo

Primeiro, mapeie cada operação da API para sua provável cota e finalidade comercial. Uma cotação instantânea, uma consulta de conta, o envio de uma ordem e uma verificação do status da ordem podem ter custos diferentes. Algumas APIs contabilizam requisições, enquanto outras aplicam limites separados para envio de ordens, cancelamentos ou sessões simultâneas. Um cliente que agrupa tudo em um único contador global de requisições não consegue explicar qual carga consumiu seu orçamento.

Registre o código de resposta, o endpoint, a credencial ou o identificador da conta, o peso da requisição, se fornecido, e todos os cabeçalhos de limite. Cabeçalhos comuns informam a cota restante, o horário de reinicialização ou o tempo de espera antes de uma nova tentativa. Capture-os tanto em respostas bem-sucedidas quanto em erros. Se o provedor não fornecer cabeçalhos, infira a pressão com base na frequência de respostas 429 e em testes controlados em um ambiente que não seja de produção. Não presuma que uma resposta 429 de um endpoint significa que todos os endpoints estão bloqueados.

Separe limites rígidos da integridade do serviço. Uma resposta 429 geralmente indica um limite de cota, enquanto uma resposta 5xx aponta para uma falha no servidor, embora os provedores nem sempre sigam perfeitamente essa distinção. Leia o corpo da resposta e as orientações do provedor. Um tempo limite é mais ambíguo: uma ordem pode ter sido aceita mesmo que o cliente nunca tenha recebido a confirmação. Repetir cegamente o envio de uma ordem pode criar uma duplicata, a menos que a API aceite chaves de idempotência ou que o cliente primeiro reconcilie o estado da ordem.

Para uma cobertura mais ampla da infraestrutura, a cobertura da Trading Technology sobre infraestrutura complementa os detalhes operacionais que as equipes precisam acompanhar internamente: pesos das requisições, permissões para picos e comportamento de recuperação.

Meça a pressão, não apenas as respostas 429

Conte separadamente as tentativas e as respostas bem-sucedidas. Para cada endpoint e grupo de contas, acompanhe as requisições por segundo, as respostas 429 como proporção das tentativas, as taxas de tempo limite e de respostas 5xx, o volume de novas tentativas e a fração da cota disponível consumida.

Inclua a profundidade da fila e a idade do item mais antigo. Uma taxa baixa de respostas 429 ainda pode ocultar um cliente quase saturado se as requisições estiverem na fila antes de chegar ao broker.

Use um intervalo curto para detectar picos e outro mais longo para analisar tendências. Intervalos de um segundo ou cinco segundos revelam picos que desaparecem em uma média calculada por minuto.

Mantenha a latência p50, p95 e p99 tanto para a fila do cliente quanto para a viagem completa de ida e volta da API. Identifique cada medição com a operação e o resultado. Sem essas dimensões, um aparente aumento na latência pode ser causado por consultas lentas de conta, e não por confirmações de ordens.

Entre os sinais operacionais úteis estão:

• Margem de cota: requisições disponíveis divididas pelo limite na janela relevante, quando o provedor informa os dois valores.
• Amplificação de novas tentativas: todas as tentativas divididas pelas requisições lógicas originais. Um aumento de 1.0 para 1.5 significa que cada requisição de negócio gera, em média, meia chamada extra à API.
• Idade da fila: o tempo entre uma tarefa se tornar elegível e o cliente enviá-la. Acompanhe a tarefa mais antiga, além da mediana.
• Integridade do fluxo de ordens: latência de envio e confirmação, envios rejeitados e tempos limite não resolvidos. Não misture esses dados com o tráfego somente de leitura.

Configure alertas com base em combinações, em vez de um único limite. Por exemplo, o uso sustentado da cota acima de 80 por cento, junto com o aumento da idade da fila, é motivo para limitar o tráfego proativamente, mesmo antes de aparecerem respostas 429. O valor de 80 por cento é um limite operacional inicial, não uma regra universal. Teste-o em função do tamanho dos picos, das janelas de reinicialização do provedor e do tempo de recuperação que seus fluxos de trabalho podem tolerar.

O backoff é um mecanismo de controle de tráfego

Quando uma requisição é rejeitada, tentar novamente imediatamente aumenta a carga justamente no momento de maior pressão. Use backoff exponencial com jitter para consultas que possam ser repetidas e outras operações seguras. Uma programação típica pode começar em 200 a 500 milissegundos, multiplicar o intervalo por aproximadamente dois após cada falha e limitá-lo a 5 a 30 segundos. Varie aleatoriamente o intervalo para que um grupo de clientes não retome as tentativas ao mesmo tempo.

Respeite um valor válido de Retry-After, em vez de usar um intervalo calculado localmente. Defina um número máximo de tentativas e um limite total de tempo para novas tentativas.

Quando qualquer um desses limites for atingido, envie a tarefa para uma fila com atraso ou sinalize-a para análise operacional, em vez de tentar novamente indefinidamente. Para operações não idempotentes, tente novamente apenas quando o mecanismo de idempotência da API e a lógica de reconciliação do cliente tornarem o resultado seguro.

O backoff precisa de uma condição de reinicialização. Se um cliente zerar o contador de falhas após um único sucesso, ele poderá voltar rapidamente à velocidade máxima e recriar o pico. Uma retomada gradual, como aumentar a taxa de envio permitida em etapas ao longo de dezenas de segundos, pode ser mais segura. Ajuste o intervalo ao comportamento de reinicialização documentado pelo provedor e à velocidade de crescimento da fila. Se a fila continuar envelhecendo durante a recuperação, a retomada está rápida demais ou a demanda recebida ainda excede a capacidade.

Distinga o controle de tráfego no cliente do backoff no servidor. Um token bucket pode suavizar picos locais, enquanto um limite de concorrência pode impedir que muitas requisições lentas fiquem em andamento ao mesmo tempo.

Ambos os controles protegem o cliente e o provedor, mas nenhum cria cota adicional. Meça se limitar a concorrência reduz os tempos limite e observe se o acúmulo de tarefas apenas passa da camada de rede para uma fila interna.

Limite o tráfego de acordo com a prioridade do negócio

Uma única fila com agendamento por ordem de chegada permite que consultas rotineiras ocupem a capacidade necessária para ações urgentes. Aloque orçamentos de requisições por carga de trabalho e por conta.

O envio e o cancelamento de ordens, assim como os controles de risco, geralmente precisam de uma parcela protegida; atualizações de contas, consultas históricas e análises não essenciais podem usar a capacidade excedente ou ser adiadas. A ordem exata de prioridade depende dos controles da empresa e do contrato da API do broker.

Deixe a política explícita. Por exemplo, reserve uma parcela do orçamento do cliente para o tráfego do fluxo de ordens, limite as consultas de baixa prioridade e interrompa o trabalho opcional quando a tarefa crítica mais antiga ultrapassar seu limite de latência.

Aplique limites por conta, além dos limites globais. Uma única conta com alta atividade não deve consumir toda a cota compartilhada se outras contas dependerem da mesma credencial.

Antes da produção, verifique o que acontece quando os limites entram em conflito:

• É possível enviar um cancelamento quando consultas de cotação ou de conta esgotaram o orçamento?
• Um disjuntor pausa apenas o endpoint com falha ou também bloqueia operações sem relação com ele?
• As requisições na fila podem expirar ou ficar desatualizadas antes do envio, especialmente consultas sensíveis ao preço?
• Os operadores conseguem identificar claramente qual conta ou serviço está consumindo capacidade?

Esses controles precisam de um modo de falha definido. Descartar atualizações de dados de mercado desatualizadas pode ser aceitável; descartar silenciosamente um cancelamento, não.

Preserve contexto suficiente para reproduzir ou reconciliar o trabalho adiado e torne visível a expiração da fila em alertas e logs. As equipes que acompanham tecnologia de brokers e operações de plataformas ainda devem validar esses comportamentos em relação à própria topologia de contas e à documentação dos provedores.

Calcule o custo do excesso de demanda

Os incidentes de limite de taxa consomem mais do que a cota da API. Novas tentativas aumentam a carga, tarefas enfileiradas elevam a latência e a reconciliação exige esforço operacional. As faixas abaixo são estimativas típicas de planejamento para diferentes implementações de API, não garantias dos provedores nem resultados auditados. Meça os valores locais antes de definir objetivos de serviço.

Traduza esses custos em um orçamento de capacidade. Suponha que um cliente envie 20 requisições lógicas por segundo e que as novas tentativas elevem a proporção de tentativas para 1.5. Agora ele está fazendo 30 tentativas por segundo, sem contar consultas periódicas nem outros serviços que compartilham a credencial. Se o limite configurado para o cliente for de 35 tentativas por segundo, restam apenas cinco para todo o restante do trabalho. Esse é um nível operacional frágil, mesmo que o limite publicado pelo provedor seja maior.

Meça também o custo de limitar o tráfego. Um teto restritivo pode aumentar a idade da fila e atrasar tarefas úteis, enquanto um teto permissivo demais pode provocar ciclos repetidos de rejeição e recuperação. Compare a idade p95 de cada carga de trabalho com seu prazo de negócio e ajuste os orçamentos para manter o trabalho crítico dentro do próprio limite. Informe tanto o tráfego protegido quanto o trabalho adiado, para que um fluxo de ordens aparentemente saudável não esconda um acúmulo crescente em outras áreas.

Valide os limites sem prejudicar o fluxo de ordens

Não descubra os limites de produção enviando picos aos endpoints de ordens em operação. Reproduza os padrões de requisição em um ambiente de testes cujos limites sejam representativos e, depois, confirme o comportamento em produção por meio de observação conservadora e coordenação com o provedor. As cotas do ambiente de testes podem ser diferentes, então considere-o útil para a lógica do cliente e menos útil para estimar a capacidade em produção.

Use esta lista numerada antes de alterar o controle de tráfego de um cliente:

1. Inventarie os limites: documente o endpoint, a credencial, a conta, o peso da requisição, o limite de concorrência, a janela de reinicialização e os cabeçalhos de resposta do provedor.
2. Estabeleça a demanda de referência: colete as taxas de requisições por segundo e por intervalos de cinco segundos, a latência p95 e p99, a taxa de respostas 429, a amplificação de novas tentativas e a idade da fila durante pelo menos um período de trading representativo.
3. Classifique as operações: marque as requisições como críticas para ordens, críticas para risco, sensíveis à atualização ou adiáveis. Registre quais chamadas podem ser repetidas com segurança e quais exigem reconciliação.
4. Defina os orçamentos: configure limites por endpoint e por conta abaixo do limite conhecido, com capacidade reservada para operações críticas e uma justificativa documentada para cada margem.
5. Teste os caminhos de falha: simule respostas 429, respostas atrasadas, tempos limite e erros 5xx. Verifique o jitter, os limites de tentativas, a idempotência e a expiração da fila.
6. Revise a recuperação: verifique se o tráfego volta gradualmente, se as filas são esvaziadas dentro dos objetivos de serviço e se os alertas identificam o endpoint e a conta por trás da pressão.

Mantenha os painéis no mesmo nível de granularidade da política de controle. Se o limite de tráfego é aplicado por conta, mas o monitoramento mostra apenas uma média global, será difícil detectar um pico específico de uma conta. Reavalie os limites após mudanças nos endpoints, lançamentos de novas contas, alterações na frequência das consultas periódicas ou atualizações da política do provedor. Uma pequena revisão programada detecta desvios de cota antes que se tornem um incidente em produção.

Nesta semana, instrumente e represente em um gráfico a amplificação de novas tentativas por endpoint, junto com a idade da fila, para uma API em produção.

#limitação de requisições da API do broker #limite de taxa da API #backoff exponencial #HTTP 429 #orçamentos de requisições #confiabilidade da API de ordens #lógica de repetição #monitoramento de API