Teste de carga em plataforma de trading: checklist de lançamento

Subestimar em 2x o pico de fluxo de ordens pode fazer um broker perder a janela de lançamento: as filas crescem, as confirmações de ordens não atingem as metas e a equipe de operações começa a conciliar o estado manualmente. O teste de carga antes da entrada em produção permite descobrir se a infraestrutura de trading consegue absorver a carga do lançamento, e não apenas se um endpoint isolado de API responde rapidamente.

O trabalho é prático, mas precisa de limites bem definidos. Este checklist foi elaborado para ser executado nesta semana, em um ambiente semelhante ao de produção, com uma carga de trabalho registrada e limites de aprovação acordados antes do primeiro teste. Ele cobre o fluxo desde a solicitação do cliente até risco, execução e relatórios, incluindo a recuperação em vez de deixá-la para um exercício posterior.

Defina primeiro a carga de trabalho e os limites

Comece pela previsão de lançamento do produto e teste acima dela. Separe a atividade média esperada dos picos curtos. Uma plataforma que processa 500 solicitações de ordens por segundo em média ainda pode ter dificuldades com um pico de 1,500 solicitações se elas atingirem a mesma conta, o mesmo símbolo ou a mesma partição de risco ao mesmo tempo.

Use dados de produtos existentes, quando disponíveis, mas inclua uma margem razoável para o crescimento do lançamento. Faixas típicas de planejamento são 1.5x a 3x a vazão de pico prevista e 2x a 5x o número esperado de sessões simultâneas.

Modele toda a combinação de transações, não um fluxo de envios de ordens idênticas. Inclua logins e atualizações de sessão, assinaturas de dados de mercado, ordens novas e alteradas, cancelamentos, execuções, consultas de saldo e posição, além de reconexões após uma breve interrupção de rede. Para um broker ou uma prop firm, o mecanismo de risco pode ser o serviço limitante mesmo quando o gateway e a conexão com matching ou execução parecem estar funcionando normalmente. Inclua ordens rejeitadas e verificações de risco na carga de trabalho, pois elas também consomem capacidade de processamento e do banco de dados.

Registre os limites de aprovação antes dos testes. Use objetivos de nível de serviço compatíveis com o produto e o mercado, em vez de escolher um limite depois de ver os resultados. Um conjunto inicial útil inclui:

• Latência de confirmação de ordens nos percentis p50, p95 e p99, medida desde o envio pelo cliente até a resposta que ele efetivamente recebe.
• Vazão de ordens e cancelamentos, com uma contagem separada de solicitações aceitas, rejeitadas, expiradas e duplicadas.
• Atraso na entrega de dados de mercado e atualizações perdidas ou fora de sequência, medidos no limite da aplicação.
• Latência de decisão de risco, tamanho da fila, uso de conexões com o banco de dados e atraso no message broker.
• Tempo de recuperação após a reinicialização de um serviço, perda de rede ou lentidão de uma dependência, incluindo o tempo até a conciliação das posições e do estado das ordens.

Defina um critério rígido de reprovação para falhas de integridade. Qualquer execução duplicada, ordem aceita perdida, posição inconsistente ou aceitação não autorizada de uma ordem reprova o teste, independentemente da latência média. Quem acompanha a cobertura de infraestrutura da Trading Technology reconhecerá a diferença: os números de capacidade importam, mas apenas quando considerados junto com os controles e a integridade do estado.

Monte um ambiente de teste semelhante ao de produção

Use as mesmas versões de software, configurações, tamanhos de instância, caminhos de rede e armazenamentos de dados previstos para o lançamento. Se o desenho de produção usa gateways separados por região, teste cada rota. Um ambiente menor ainda pode revelar gargalos da aplicação, mas não permite estabelecer a capacidade de produção por simples multiplicação. Bloqueios compartilhados no banco de dados, taxas de acerto de cache, vizinhos ruidosos e limites de rede nem sempre escalam de forma linear.

Use contas e instrumentos sintéticos com distribuições realistas. Mil usuários virtuais enviando ordens para um único símbolo líquido formam um teste útil de chave quente, mas não representam um perfil de lançamento típico. Distribua o tráfego entre símbolos comuns e diferentes tamanhos de conta, depois acrescente um pico concentrado para revelar partições ou estados de risco compartilhados. Use um feed de dados de mercado com preços variáveis e taxas de atualização realistas; uma amostra estática pode ocultar custos de distribuição downstream e serialização.

Inclua o gerador de carga no desenho do teste. Execute-o em um host ou cluster separado, confirme que ele tem capacidade de CPU e rede disponível e monitore-o com o mesmo cuidado que a plataforma. Se o gerador saturar primeiro, o máximo reportado não representa o limite da plataforma. Sincronize os relógios entre clientes e serviços e registre os horários de criação da solicitação, recebimento no gateway, decisão de risco, envio ao mercado e resposta ao cliente. Isso permite que a equipe diferencie a latência da aplicação dos atrasos de rede e de execução externa.

Prepare um arquivo ou script de carga de trabalho reproduzível, com uma semente fixa. Registre o número de contas, o aumento gradual de sessões, a combinação de ordens, os símbolos, as taxas de solicitação e as falhas injetadas. Mantenha os dados de teste isolados das contas e rotas de mercado de produção. Para mercados externos, use um simulador certificado ou um ambiente de teste controlado e deixe explícitos os limites de solicitações de saída. O teste nunca deve enviar tráfego sem controle a um mercado ativo.

Antes da execução, verifique se logs, tracing e métricas estão habilitados no nível necessário para o diagnóstico, sem alterar inadvertidamente o desempenho com excesso de logs de depuração. Retenha as amostras brutas de latência, não apenas as médias dos painéis. As médias ocultam o comportamento da cauda, e até um único número p99 pode esconder um pico breve, mas prejudicial, durante um aumento de carga ou failover.

Execute o teste em etapas controladas

Não comece com a carga máxima. Uma execução em etapas ajuda a separar os efeitos de aquecimento de um limite real de capacidade e dá tempo para a equipe interromper o teste antes que as filas se tornem irrecuperáveis.

Mantenha cada etapa por tempo suficiente para revelar crescimento do uso de memória, vazamentos de conexão e persistência atrasada. Para a maioria das verificações de lançamento, um período estável de 15 a 30 minutos por nível de carga é um bom ponto de partida; serviços que devem permanecer ocupados por horas precisam de testes de longa duração.

Siga esta ordem de execução e registre o horário de início, a versão da carga de trabalho e o resultado de cada etapa:

1. Referência: Execute uma carga pequena e representativa por 10 a 15 minutos. Confirme se os registros de data e hora, contadores e tracing estão de acordo e capture o uso de recursos em repouso.
2. Aumento gradual: Aumente as sessões e solicitações em etapas, normalmente de 10 a 20 per cent a cada poucos minutos. Observe o tamanho da fila e a latência de cauda, não apenas o uso de CPU.
3. Pico esperado: Mantenha a carga no pico previsto para o lançamento por tempo suficiente para atingir um estado estável. Verifique cada limite de aprovação e compare a resposta visível ao cliente com os tempos internos dos serviços.
4. Pico de demanda: Teste a margem acordada, normalmente 1.5x a 3x o pico previsto. Mantenha uma combinação de ordens representativa e depois execute um pico separado para um símbolo ou uma conta muito ativos.
5. Teste prolongado: Mantenha uma carga elevada e realista por pelo menos 60 a 120 minutos, se o tempo permitir. Acompanhe a memória, as conexões abertas, o comportamento do cache, os pools do banco de dados e as tendências das filas.
6. Recuperação: Enquanto a carga continua, reinicie uma instância de serviço não crítica ou introduza um atraso controlado em uma dependência. Verifique se o tráfego é redirecionado conforme previsto e se o estado das ordens permanece consistente.
7. Redução da carga: Reduza a carga e confirme se as filas são esvaziadas, o uso de recursos retorna aos níveis de referência e nenhuma tarefa de conciliação em segundo plano fica bloqueada.

Altere uma variável de cada vez durante os testes de diagnóstico. Se um teste combinar failover do banco de dados, um pico de logins e uma desconexão do mercado, o resultado pode revelar uma falha sem identificar sua causa. Depois que os testes isolados forem aprovados, execute um cenário combinado que se aproxime do risco de lançamento que mais preocupa a equipe de operações.

Não considere uma execução bem-sucedida enquanto houver ordens aceitas aguardando em uma fila não monitorada.

Analise os números e localize o gargalo

Use a tabela como um conjunto de faixas iniciais típicas, não como compromissos universais de nível de serviço. O tipo de produto, a conectividade com o mercado, a jurisdição, as regras de ordens e a aplicação do cliente afetam os limites adequados. Antes do lançamento, a equipe deve substituir essas faixas por objetivos próprios, aprovados formalmente.

Interprete as métricas em conjunto. CPU alta no gateway com uso normal do banco de dados pode indicar problemas de serialização, autenticação ou registro de logs por solicitação. CPU baixa junto com o aumento da idade das filas costuma apontar para uma dependência bloqueada, esgotamento do pool de conexões ou um pool de workers subdimensionado. Um aumento repentino do p99 com p50 estável geralmente indica contenção, filas ou um vizinho ruidoso, e não uma lentidão generalizada da plataforma.

Rastreie uma pequena amostra de solicitações lentas entre os limites dos serviços. Procure chamadas repetidas ao banco de dados, gravações síncronas de auditoria, contenção de bloqueios, consultas lentas de risco e ciclos de novas tentativas. Verifique se as novas tentativas ampliam a demanda: se uma chamada downstream expira e cada cliente tenta de novo imediatamente, o tráfego de novas tentativas pode superar a carga original. Quando apropriado, adicione novas tentativas limitadas com jitter e verifique se as chaves de idempotência impedem que um envio repetido crie uma segunda ordem.

Em cada etapa, salve um breve pacote de evidências: a definição da carga de trabalho, a versão da implantação, capturas das métricas, percentis de latência, contagens de erros, idade das filas e anotações dos operadores. Inclua uma lista de desvios conhecidos em relação à produção. Uma execução sem configuração reproduzível é difícil de comparar após uma mudança de código ou infraestrutura.

Teste falhas, recuperação e o critério de lançamento

A capacidade, por si só, não comprova que o produto está pronto para o lançamento. Defina um pequeno conjunto de falhas controladas que reflita a arquitetura real e as consequências da perda de cada dependência. Comece com uma instância de serviço e só então passe para uma falha no banco de dados ou no message broker, se o ambiente de teste estiver isolado e o procedimento de recuperação for conhecido. Nunca improvise testes destrutivos em um ambiente compartilhado.

Para cada falha, verifique tanto a resposta técnica quanto o fluxo de trabalho dos operadores. A verificação de integridade retira a instância com falha? Os clientes recebem uma mensagem clara de tempo esgotado ou uma indicação enganosa de sucesso? As ordens em andamento são consultadas ou reproduzidas com segurança? A equipe de operações consegue identificar as contas afetadas e conciliá-las com o sistema oficial de registro? Um failover que restabelece a vazão, mas deixa incerto o estado das ordens, não é aprovado.

Antes da aprovação final, confirme o seguinte com as equipes de engenharia e operações e com o responsável pelo produto:

• As cargas de trabalho de pico e de pico de demanda acordadas foram executadas sem falhas de integridade.
• A latência, as taxas de erro e a idade das filas permaneceram dentro dos limites definidos antes dos testes, ou têm um responsável nomeado e uma exceção documentada.
• O escalonamento automático, o redirecionamento de tráfego e os limites de conexão funcionaram conforme configurados, incluindo os períodos de espera para redução de escala.
• Os alertas de monitoramento foram disparados com antecedência suficiente para que um operador pudesse agir, e o runbook identifica o responsável pelo serviço e o caminho de escalonamento.
• Os critérios de rollback são explícitos. Alguns exemplos são violação sustentada do p99, aumento da idade das filas, alta nas rejeições de ordens ou qualquer divergência entre posições e ordens aceitas.
• As evidências do teste e as falhas não resolvidas estão anexadas à decisão de lançamento, com uma data de novo teste para cada correção relevante.

Dimensione o critério de lançamento de acordo com o produto. Um novo símbolo em uma infraestrutura consolidada pode exigir apenas um teste direcionado de chave quente e dados de mercado.

Uma nova rota de execução, um novo mecanismo de risco ou um novo modelo de conta justifica uma reprodução mais abrangente e um teste de falhas. Para mais contexto sobre infraestrutura de brokers e operações de plataformas, consulte nossa cobertura de tecnologia de trading.

Agende nesta semana uma revisão de 90 minutos da carga de trabalho de lançamento e saia com o arquivo de reprodução, os limites de aprovação e um responsável nomeado pelo rollback.

#infraestrutura de prop firm #testes de failover #desempenho de plataformas de trading #testes de plataformas de broker #testes de carga do fluxo de ordens #capacidade de sistemas de trading #testes de latência #testes de estresse de dados de mercado