Estudo de Caso - Testes de Carga na Consulta de Apólices

Garantir a performance de sistemas críticos é um desafio constante para empresas que lidam com grandes volumes de dados e operações sensíveis. No caso dessa API, a funcionalidade de consulta de apólices é uma das mais utilizadas — especialmente por corretoras de grande porte, que demandam agilidade e estabilidade em todas as requisições.

Como parceiros tecnológicos e estratégicos do cliente, nos propusemos a criar um plano de teste de carga completo e técnico, para assegurar que a solução pudesse atender a grandes corretoras, mesmo em momentos de pico. Nosso diferencial foi abordar o problema de forma técnica e pragmática, com testes reais e mensuráveis.

O desafio

A consulta de apólices dessa API realiza chamadas ao IGC, um intermediário responsável por buscar dados de apólices com seguradoras integradas. Ou seja: trata-se de uma operação altamente sensível e sujeita a picos de uso, sobretudo em dias de fechamento de propostas ou quando há operações em lote por parte das corretoras.

Até então, não havia sido realizado nenhum teste de carga específico sobre essa funcionalidade. Isso significava atuar com uma margem de incerteza em relação ao comportamento do sistema sob alta demanda — um risco considerável em ambientes produtivos.

A estratégia adotada

Optamos por utilizar o Locust, uma ferramenta de código aberto baseada em Python, ideal para simular múltiplos usuários e monitorar métricas em tempo real. Para nos aproximarmos da realidade de uso, combinamos essa simulação com métricas reais extraídas do New Relic, durante a janela com maior volume de acessos no sistema.

Além disso, utilizamos distribuição Gaussiana para simular variações naturais no tempo de espera entre requisições, aproximando ainda mais os testes de um ambiente realista.

Buscamos responder duas perguntas principais: Como a API se comporta com uma carga compatível com o uso real? A partir de que ponto o sistema começa a apresentar degradação de desempenho?

Criamos scripts que reproduziam o comportamento esperado de usuários reais, incluindo autenticações, chamadas ao endpoint de consulta e variações de tempo entre as ações. Isso nos permitiu observar como o sistema reagia à medida em que aplicávamos o teste ramp-up, aumentando gradualmente o número de requisições simultâneas.

Teste 01 - Cargas Realistas

O primeiro teste replicou uma carga semelhante à registrada no ambiente de produção. Para isso:

• Número de usuários simulados: 8.

• Média de requisições por minuto (RPM): 1,066 RPM.

  • Valores registrados:

    • 10/02: 0,6 RPM

    • 11/02: 1,96 RPM

    • 12/02: 1,47 RPM

    • 13/02: 0,7 RPM

    • 14/02: 0,6 RPM
      

A média foi calculada somando-se os valores diários e dividindo-se pelo número total de dias, resultando em 1,066 rpm. Para simular esse funcionamento numa capacidade superior, executamos o teste com 1.4 RPM:

Com a biblioteca random, de forma simplifica, calculamos a distribuição Gaussiana desse valor:

 #Quanto maior o desvio padrão maior a variação
2 desvio_padrão = 90
3 random.gauss(342, desvio_padrao)

Resultados

Durante a execução (das 08h às 11h), o sistema permaneceu estável. Nenhum aumento relevante no tempo de resposta foi observado, indicando que a API comporta tranquilamente o volume atual e até mesmo um pouco acima.

Teste 02 - Degradação

Para avaliar o limite do sistema, realizamos um teste de degradação. A carga foi aumentada gradualmente, reduzindo o tempo de espera entre as requisições ao longo do tempo. O número de usuários foi escalonado (45, 50, 60), e o tempo entre requisições diminuiu conforme a média de resposta se mantinha baixa.

O script ajustava o tempo entre requisições dinamicamente, de acordo com o tempo médio de resposta:

python
CopiarEditar
def wait_time(self):
    if avg < 12000:        
        self.request_wait = self.request_wait - 10
    request_wait = max(20, self.request_wait) 
    return random.gauss(request_wait, 20)

Além disso, os testes envolveram diferentes recursos simulados para garantir diversidade nas requisições.

Resultados

À medida que o RPM aumentava, o tempo de resposta também crescia. A partir de 83 RPM, observamos um salto de 3x no tempo médio de resposta, caracterizando o início da degradação do sistema. Desse total, 55 RPM estavam concentrados apenas na API de consulta.

 A origem da lentidão foi atribuída principalmente ao banco de dados do ERP externo, responsável pela execução das queries SQL utilizadas nessa rota.

O que observamos

À medida que a carga aumentava, conseguimos identificar pontos específicos de gargalo, especialmente em dependências externas sem fallback e em limitações de tempo de resposta do banco de dados. Felizmente, não houve colapso do sistema, mas sim uma degradação controlada, o que é um sinal de que a arquitetura está bem estruturada, mas ainda tem espaço para melhorias pontuais.

Outro ponto relevante foi perceber diferenças importantes entre os testes feitos em ambientes de homologação e os realizados em produção. A execução real trouxe dados mais precisos, o que reforça a importância de simulações no ambiente final — desde que feitas com cautela.

Impactos e aprendizados

O principal benefício para o cliente foi a segurança de saber que a funcionalidade de consulta de apólices está preparada para lidar com grandes volumes de uso. Para as corretoras que utilizam o sistema, isso se traduz em estabilidade, fluidez na navegação e mais confiança nas operações do dia a dia.

Internamente, o projeto nos permitiu consolidar boas práticas em testes de carga e performance, além de gerar uma documentação técnica que poderá ser reaproveitada em outros contextos críticos — economizando tempo e padronizando a abordagem.

Conclusão

Esse estudo de carga mostrou, na prática, como uma estratégia bem planejada pode trazer segurança técnica e operacional para sistemas complexos. Com testes realistas, métricas bem monitoradas e foco em cenários reais de uso, foi possível validar o desempenho da API e identificar oportunidades de evolução. Para a Arbeit Studio, mais do que um projeto técnico, foi a chance de reafirmar nosso compromisso com entregas robustas e sustentáveis.