Situação (antes da nossa atuação)
A aplicação de motor de cálculo de risco da Icatu Seguros realizava comunicações com APIs de terceiros por meio de um job agendado e controlado via Control-M, executado a cada cinco minutos. Esse job acionava um endpoint da própria aplicação para iniciar a comunicação com a API externa — uma abordagem pouco adequada, pois criava uma dependência externa para um processo interno crítico, limitando o controle transacional e dificultando a manutenção da arquitetura.
A integração com a API de terceiros exige — ainda hoje — que os dados de entrada sejam inseridos diretamente em um banco de dados mantido on-premise pela Icatu. Para isso, o PowerCenter buscava os dados do banco interno da aplicação, inseria no banco do terceiro e acionava a API para iniciar a classificação de risco. Após a conclusão, o PowerCenter novamente acessava a base externa para recuperar o resultado da classificação, incluindo informações detalhadas de risco e notícias associadas.
Além dessa complexidade de integração, a aplicação apresentava limitações severas em termos de performance e escalabilidade. O uso de um job periódico tornava-se um gargalo em momentos de maior volume, impactando significativamente o tempo de resposta. Os endpoints da aplicação eram todos síncronos, o que gerava problemas graves de thread starvation. No endpoint de entrada de propostas, por exemplo, duas APIs internas (listas de profissões e países) eram chamadas a cada requisição, mesmo com dados que raramente se alteram, e sem qualquer tipo de cache — o que gerava lentidão desnecessária. A arquitetura como um todo dificultava a escalabilidade, e a equipe responsável pela aplicação vivia um dia a dia de alta complexidade operacional, precisando intervir manualmente em diversas propostas com erros no processamento, o que afetava tanto a produtividade quanto a satisfação dos usuários internos e clientes.
Implicações
As limitações da arquitetura anterior geravam impactos significativos tanto na operação quanto na experiência dos usuários:
- Tempo de resposta elevado: O uso de jobs periódicos e chamadas síncronas comprometia a agilidade da aplicação, prejudicando a tomada de decisão em tempo real, especialmente em momentos de pico de requisições;
- Problemas graves de performance: A ausência de processamento assíncrono e o excesso de chamadas redundantes a APIs internas levavam à exaustão de threads, instabilidade e lentidão nos principais endpoints da aplicação;
- Alta complexidade operacional: A equipe responsável pela manutenção da aplicação gastava grande parte do tempo monitorando fluxos com erro, ajustando manualmente propostas e investigando bugs recorrentes, o que comprometia a produtividade e aumentava a chance de falhas humanas;
- Satisfação dos usuários comprometida: Os atrasos e falhas recorrentes no processamento das propostas geravam insatisfação nas equipes consumidoras da aplicação, como compliance e sistemas de produto;
- Dificuldade de escalar a solução: A arquitetura existente não suportava bem aumentos de volume, limitando a capacidade da Icatu de evoluir e inovar em seus produtos sem enfrentar gargalos técnicos.
O que fizemos
A atuação da EximiaCo se deu em múltiplas frentes, visando não apenas melhorar a performance da aplicação de cálculo de risco da Icatu, mas também garantir escalabilidade, estabilidade e maior eficiência operacional.
Começamos pela transformação dos principais endpoints da aplicação, que passaram a operar de forma assíncrona, junto com os métodos internos necessários. Essa mudança eliminou os problemas de thread starvation e melhorou significativamente a capacidade de resposta da aplicação. Em paralelo, adicionamos mecanismos de cache para armazenar tokens de autenticação usados nas comunicações com APIs de terceiros, bem como os resultados das APIs internas de lista de profissões e países — reduzindo drasticamente a quantidade de chamadas externas e aumentando a performance geral.
Embora a equipe de arquitetura da Icatu inicialmente tenha sugerido uma abordagem baseada em filas de mensageria e workers, propusemos uma alternativa mais simples e igualmente escalável, baseada na biblioteca Workflow Core, que permite orquestração de workflows de longa duração. Essa arquitetura, implementada com containers em Kubernetes, possibilita escalar horizontalmente os workers conforme a demanda, garantindo ótimo desempenho e maior facilidade de manutenção.
Além da mudança de arquitetura, realizamos uma ampla melhoria na estrutura de código da aplicação e no pipeline de CI/CD, garantindo um fluxo de build e deploy mais eficiente e adequado à nova arquitetura. Incluímos ainda a implementação de funcionalidades que estavam pendentes desde o início do projeto, como o controle de validade de dados complementares — que permite evitar chamadas desnecessárias a APIs de terceiros quando os dados enriquecidos já estiverem disponíveis e válidos, reduzindo custo e tempo de processamento.
Também investimos fortemente na qualidade e estabilidade do sistema. Adicionamos testes de unidade e testes de integração nos principais pontos do fluxo de classificação de risco de propostas, o que trouxe maior segurança contra regressões e melhorou a confiabilidade das entregas. A documentação da aplicação foi revisada e ampliada, promovendo um entendimento mais claro do funcionamento da solução e facilitando o onboarding de novos desenvolvedores.
Por fim, resolvemos um problema crítico do ambiente de desenvolvimento: até então, era necessário utilizar a base de dados do ambiente de Teste para rodar a aplicação localmente, o que dificultava a validação e os testes por parte dos desenvolvedores. Adicionamos um container de banco local, que sobe junto com a aplicação, permitindo que cada desenvolvedor utilize sua própria base com dados controlados, melhorando significativamente a produtividade e a autonomia da equipe.
Entregáveis
- Nova arquitetura de processamento baseada em workers assíncronos com Workflow Core, executando em containers no Kubernetes;
- Transformação dos principais endpoints da aplicação para processamento assíncrono;
- Implementação de cache para tokens de autenticação e resultados de APIs internas (profissões e países);
- Refatoração e melhoria da estrutura do código-fonte da aplicação;
- Implementação de feature para controle de validade de dados complementares, evitando chamadas desnecessárias a APIs de terceiros;
- Reestruturação completa do pipeline de CI/CD, alinhado à nova arquitetura;
- Adição de testes de unidade e testes de integração nos fluxos críticos da aplicação;
- Melhoria e ampliação da documentação da aplicação;
- Containerização de banco de dados local para uso em ambientes de desenvolvimento, com dados independentes por desenvolvedor.
Feedbacks
Embora não tenha havido um feedback formal documentado por parte da Icatu, os ganhos alcançados com a nova arquitetura e com as melhorias implementadas foram amplamente reconhecidos pelos stakeholders do projeto. Casos de processamento de mais de 1.000 propostas em um mesmo horário, todas concluídas com sucesso dentro da mesma hora, demonstram a eficiência da solução — um cenário antes impensável, considerando que em casos onde havia uma carga de muitas propostas, alguns fluxos poderiam levar dias para serem processados.
Segundo o Product Owner da aplicação, o desempenho atual “não se compara ao antigo”, sendo muito mais rápido e estável. Ele também destacou a mudança positiva no dia a dia da equipe: a necessidade de monitoramento contínuo e de ajustes manuais em propostas foi muito reduzida. Como resultado, as reclamações das áreas usuárias, como compliance e times de sistemas produtos consumidores do motor de cálculo, caíram expressivamente.
