Resumo Executivo

Maycon Arthuso de Carvalho; Elaine Barbosa de Figueiredo

Resumo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.

Os sistemas de software modernos enfrentam desafios cada vez mais complexos devido ao aumento da sofisticação das aplicações e à necessidade imperativa de atender a demandas dinâmicas, como alta disponibilidade e desempenho superior. No contexto específico de sistemas financeiros, os consumidores exigem métodos de pagamento que operem de maneira ágil, flexível e segura, enquanto as organizações buscam soluções confiáveis e capazes de se adaptar à volatilidade do mercado (Wang, 2024). Tais requisitos evidenciam a necessidade de arquiteturas robustas e escaláveis para lidar com a crescente complexidade das transações financeiras globais. Nesse cenário, a Arquitetura Orientada a Eventos surge como um paradigma fundamental em que o fluxo e o controle de dados são fundamentados em acontecimentos significativos. Esse modelo fornece um mecanismo para a construção de sistemas com baixo acoplamento, altamente escaláveis e capazes de processar grandes volumes de informações em tempo real de forma eficaz (Harris e Bennett, 2020). Diferentemente dos modelos tradicionais baseados na comunicação síncrona de requisição e resposta, essa abordagem permite que os serviços interajam de forma independente e assíncrona, aprimorando a resiliência e o suporte ao processamento massivo de dados, aspectos cruciais em setores como o comércio eletrônico (Muthusamy, 2025).

Um evento é definido como um acontecimento relevante que ocorre dentro ou fora da aplicação, podendo representar um problema, uma oportunidade ou uma ação específica do usuário. Estruturalmente, o evento é composto por um cabeçalho, contendo elementos como identificação, tipo, nome e data, além de um corpo que descreve minuciosamente o ocorrido (Michelson, 2006). De modo geral, essa arquitetura possui componentes responsáveis por criar os eventos, denominados produtores, que enviam as informações para um intermediário conhecido como broker. Este sistema intermediário é responsável por receber, armazenar e enviar eventos de forma confiável aos consumidores, que são as entidades projetadas para reagir de forma assíncrona, evitando dependências diretas ou acoplamento excessivo (Khriji et al., 2022). A integração desse modelo com a arquitetura de microsserviços organiza a aplicação em uma coleção de serviços pequenos e fracamente acoplados, onde cada componente é projetado para atender a uma função comercial específica, podendo ser implantado e escalado de forma independente (Nookala, 2023).

Assegurar a consistência dos dados em ambientes assíncronos exige estratégias avançadas como o padrão de segregação de responsabilidade de comando e consulta, que separa as operações de escrita das operações de leitura para permitir otimizações independentes (Vangala et al., 2022). Além disso, a captura de mudanças de estado como uma sequência de eventos imutáveis garante a rastreabilidade necessária em sistemas críticos (Muthusamy, 2025). O design desses sistemas é frequentemente orientado pelo domínio, focando em prioridades e acelerando o desenvolvimento em contextos complexos (Evans, 2003). Para viabilizar a escalabilidade e o desempenho, o uso de contêineres torna-se essencial, proporcionando uma maneira eficiente de isolar processos e criar réplicas dos serviços conforme a demanda de carga de trabalho (Rahmatulloh et al., 2022). A virtualização em nível de sistema permite que os microsserviços sejam dimensionados horizontalmente, adicionando instâncias para lidar com o aumento da carga de dados com flexibilidade e eficiência de custos (Aksakalli et al., 2021).

A metodologia aplicada consistiu em uma pesquisa experimental e exploratória, focada na implementação prática de um sistema de pagamentos para validação empírica de eficiência e escalabilidade. O processo de modelagem utilizou os princípios do design orientado ao domínio para identificar microsserviços e eventos fundamentais, operando dentro de um recorte técnico sem integrações externas complexas. O processamento de eventos foi estruturado por meio de mensagens enviadas via protocolo de transferência de hipertexto, utilizando especificamente o método de postagem para transmitir dados no corpo da mensagem. Foram definidos quatro eventos principais para o escopo operacional: a inicialização do pagamento, a aprovação após análise de fraude, a negação em caso de suspeitas e a liquidação final. O fluxo inicia-se quando uma requisição externa dispara o evento de inicialização, que é então consumido por um serviço de detecção de fraudes. Caso o pedido seja legítimo, o sistema gera o evento de aprovação; caso contrário, o evento de negação é disparado para encerrar o ciclo com status negativo. O estágio final ocorre com a liquidação do pagamento aprovado, confirmando a conclusão bem-sucedida da transação.

Para a construção do ecossistema, foram definidos três microsserviços centrais. O primeiro, focado em pagamentos, recebe as requisições iniciais e as encaminha ao broker de eventos, utilizando o padrão de segregação de responsabilidade para otimizar a performance. As operações de escrita foram direcionadas a um banco de dados objeto-relacional de código aberto, escolhido por sua robustez e integridade (PostgreSQL, 2025). Para as operações de leitura, optou-se por um banco de dados não relacional, que se destaca pela flexibilidade de modelagem e escalabilidade horizontal (MongoDB, 2025). O segundo microsserviço, destinado à detecção de fraudes, consome os eventos iniciais e utiliza um motor de regras de negócio para decidir a legitimidade da transação. Esse componente emprega o framework de regras declarativas para lidar com lógicas dinâmicas e críticas. O terceiro microsserviço é responsável pela liquidação, aplicando regras de finalização e atualizando o status das transações antes de publicar o evento de conclusão.

O gerenciamento de todas as mensagens entre os serviços foi realizado pelo Apache Kafka, uma plataforma distribuída de streaming amplamente utilizada em domínios financeiros onde o processamento em tempo real é vital (Shapira et al., 2021). O Kafka foi selecionado por sua capacidade de processar grandes volumes de dados de forma performática e confiável, garantindo baixa latência (Apache Kafka, 2025). O ecossistema foi complementado pelo Apache Zookeeper, responsável pela gestão e manutenção do cluster, garantindo a sincronização distribuída e a detecção de falhas nos nós do sistema (Apache Zookeeper, 2025). A implementação técnica utilizou a linguagem Java na versão Temurin 21 e o framework Spring Boot 3.4.4, aproveitando o suporte a múltiplas threads e a facilidade de integração com ferramentas de mensageria e persistência de dados.

A arquitetura seguiu o padrão hexagonal aliado ao design orientado ao domínio, promovendo a separação clara entre as camadas de domínio, aplicação e infraestrutura (Nivedhaa, 2024). Após o desenvolvimento, os microsserviços foram encapsulados em contêineres Docker, garantindo portabilidade e isolamento de dependências (Docker, 2025). A orquestração desses contêineres foi realizada via Kubernetes, uma plataforma projetada para gerir cargas de trabalho e facilitar a automação do escalonamento (Bose et al., 2021). Para simular o ambiente de produção, utilizou-se a ferramenta Kind, que permite a execução de clusters locais de forma leve. O monitoramento foi estruturado com o Prometheus para coleta de métricas e o cAdvisor para indicadores de recursos dos contêineres em tempo real (Google, 2025). A visualização dos dados foi centralizada em painéis do Grafana, permitindo a análise de tendências e o comportamento do sistema sob estresse (Khan, 2020).

A avaliação de desempenho foi conduzida por meio de testes de carga rigorosos utilizando a ferramenta K6. Os testes foram estruturados em cinco estágios distintos ao longo de 900 segundos: um aumento progressivo de zero a 100 usuários virtuais em 90 segundos; uma elevação para 300 usuários em 180 segundos; o alcance do pico de 500 usuários em mais 180 segundos; a manutenção dessa carga máxima por 360 segundos; e, finalmente, uma redução gradual para zero em 90 segundos. Foram monitoradas métricas de vazão, latência de processamento, taxas de erro e consumo de recursos computacionais como CPU e memória. A escalabilidade horizontal foi testada em quatro cenários: o primeiro com uma única instância de cada serviço; o segundo com duas instâncias do serviço de detecção de fraudes; o terceiro adicionando uma segunda instância ao serviço de pagamentos; e o quarto com duas instâncias para todos os componentes.

Os resultados obtidos no primeiro cenário, com apenas uma réplica por componente, revelaram um tempo total de processamento de três horas, 30 minutos e 40 segundos para 146.507 requisições. Nesse estágio, o serviço de detecção de fraudes apresentou um uso moderado de CPU de 35,8% e consumo de 676,8 MB de memória, enquanto a vazão média foi de 161 requisições por segundo. A latência média registrou 114 ms, com percentis elevados de 322 ms e 375 ms para as transações mais lentas. No segundo cenário, ao dobrar o número de instâncias do componente de detecção de fraudes, observou-se uma redução drástica no tempo total de processamento para duas horas, um minuto e 43 segundos. Embora o sistema tenha processado um volume ligeiramente menor de 129.565 requisições, a eficiência na gestão da fila de eventos foi notória, com o uso de CPU do serviço de fraude subindo para 54,7% e o consumo de memória atingindo 801,4 MB.

No terceiro cenário, com a adição de mais uma réplica ao serviço de pagamentos, o tempo de processamento estabilizou em duas horas, sete minutos e 11 segundos para 135.789 requisições. A vazão média caiu para 145 requisições por segundo e a latência média subiu significativamente para 311,72 ms. Esse aumento na latência, acompanhado por percentis de 95% atingindo 1,01 s, sugere que a introdução de mais réplicas começou a gerar sobrecargas de comunicação e complexidade na coordenação dos eventos. O quarto cenário, com duas instâncias para todos os serviços, processou 132.008 requisições em duas horas, 14 minutos e 54 segundos. A vazão média reduziu para 136 requisições por segundo e a latência média atingiu seu pico de 329 ms, com o percentil de 99% chegando a 947 ms. O consumo de CPU no serviço de liquidação disparou para 46,0%, indicando que a redistribuição de carga pode gerar picos de consumo em módulos específicos que anteriormente não eram gargalos.

A análise comparativa demonstra que o aumento da quantidade de réplicas impacta diretamente o consumo de recursos e a agilidade do sistema. O serviço de detecção de fraudes consolidou-se como o componente mais sensível à escalabilidade, pois sua duplicação no cenário dois foi o fator que mais contribuiu para a redução do tempo total de execução. Entretanto, os dados indicam que a escalabilidade horizontal não é linearmente infinita em termos de benefício; a partir de certo ponto, o custo de coordenação entre as instâncias e o broker de eventos introduz atrasos que prejudicam a latência percebida pelo usuário final. O consumo de memória foi consistentemente liderado pelo módulo de detecção de fraudes em todos os cenários, variando entre 676,8 MB e 801,4 MB, o que o caracteriza como o serviço mais exigente do ecossistema.

A redução gradual da vazão de 161 para 136 requisições por segundo entre o primeiro e o quarto cenário reforça a tese de que o sistema enfrenta dificuldades crescentes para manter o desempenho máximo conforme a infraestrutura se torna mais complexa. A latência média, que saltou de 114 ms para 329 ms, evidencia o impacto do overhead de rede e da gestão de múltiplas conexões assíncronas. Apesar desses desafios, a taxa de sucesso manteve-se em 100% em todos os testes, sem a ocorrência de erros de processamento, o que valida a resiliência da arquitetura orientada a eventos e a eficácia do Apache Kafka como mediador confiável. A utilização estratégica de recursos, priorizando a replicação apenas nos componentes identificados como gargalos, mostrou-se uma abordagem mais eficiente do que o escalonamento indiscriminado de todos os serviços.

Conclui-se que o objetivo foi atingido, uma vez que a implementação da arquitetura de microsserviços baseada em eventos demonstrou ser eficaz para melhorar o desempenho e a escalabilidade em sistemas de pagamentos. A análise dos dados evidenciou que a identificação de componentes críticos, como o serviço de detecção de fraudes, é essencial para uma gestão estratégica de recursos, permitindo reduções significativas no tempo de processamento. Embora a escalabilidade horizontal tenha proporcionado ganhos de vazão em cenários específicos, observou-se que o aumento excessivo de réplicas pode introduzir complexidades e latências adicionais devido ao overhead de comunicação. A utilização de padrões como CQRS, mensageria e orquestração via Kubernetes garantiu a integridade e a resiliência do sistema sob alta carga. O estudo reforça a necessidade de um planejamento cuidadoso na alocação de instâncias para equilibrar o desempenho operacional com o consumo de recursos computacionais, consolidando a arquitetura orientada a eventos como uma solução robusta para as demandas dinâmicas do setor financeiro contemporâneo.

Referências Bibliográficas:

Aksakalli, I.K.; Çelik, T.; Can, A.B.; Tekinerdoğan, B. 2021. Deployment and communication patterns in microservice architectures: a systematic literature review. Journal of Systems and Software, 180(1): 111014.

APACHE KAFKA. Apache Kafka. Disponível em: <https://kafka.apache.org/>. Acesso em: 12 set. 2025.

APACHE ZOOKEEPER. Welcome to Apache ZooKeeper. Disponível em: <https://zookeeper.apache.org/>. Acesso em: 12 set. 2025.

Bose, D.B.; Rahman, A.; Shamim, S.I. 2021. “Under-reported” security defects in kubernetes manifests. 2021 IEEE/ACM 2nd International Workshop on Engineering and Cybersecurity of Critical Systems [EnCyCriS].

DOCKER INC. 2025. What is Docker? Disponível em: Disponível em: <https://docs.docker.com/get-started/docker-overview/>. Acesso em: 03 jul. 2025.

Evans, E. 2003. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley Professional. Boston, MA, EUA.

GOOGLE. cAdvisor. Disponível em: <https://github.com/google/cadvisor>. Acesso em: 13 set. 2025.

Harris, E.; Bennett, O. 2020. Event-driven architectures in modern systems: designing scalable, resilient, and real-time solutions. International Journal of Trend in Scientific Research and Development, 4(6): 1958–1976.

Khan, F. 2020. Microservices Metrics Visualization. Dissertação de mestrado em Desenvolvimento de software. Tampere University, Tampere, Finlândia.

Khriji, S.; Benbelgacem, Y.; Chéour, R.; Houssaini, D.E. 2022. Design and implementation of a cloud-based event-driven architecture for real-time data processing in wireless sensor networks. The Journal of Supercomputing, 78(3): 3374–3401.

Michelson, B.M. 2006. Event-driven architecture overview. Patricia Seybold Group, 2(12): 10 1571.

MONGODB. Welcome to the MongoDB Docs. Disponível em: <https://www.mongodb.com/docs/>. Acesso em: 13 set. 2025.

Muthusamy, K. 2025. Event-driven data engineering in microservices architectures. International Journal of Emerging Trends in Computer Science and Information Technology, 1(1): 36–43.

Nivedhaa, N. 2024. Software architecture evolution: patterns, trends, and best practices. International Journal of Computer Sciences and Engineering [IJCSE], 1(2): 1–14.

Nookala, G. 2023. Microservices and data architecture: aligning scalability with data flow. International Journal of Digital Innovation, 4(1).

POSTGRESQL. PostgreSQL: About. Disponível em: <https://www.postgresql.org/>. Acesso em: 13 set. 2025.

Rahmatulloh, A.; Nugraha, F.; Gunawan, R. 2022. Event-driven architecture to improve performance and scalability in microservices-based systems. International Conference Advancement in Data Science, E-learning and Information Systems [ICADEIS].

Shapira, G.; Palino, T.; Sivaram, R.; Petty, K. 2021. Kafka: The Definitive Guide. 2ed. O’Reilly Media. Sebastopol, CA, EUA.

Vangala, S.R.; Kasimani, B.; Mallidi, R.K. 2022. Microservices event driven and streaming architectural approach for payments and trade settlement services. 2nd International Conference on Intelligent Technologies [CONIT].

Wang, Y. 2024. Optimizing Payment Systems with Microservices and Event-Driven Architecture: The Case of Mollie Platform. Dissertação de mestrado em Ciência da computação. Universiteit van Amsterdam, Amsterdã, Países Baixos.

Resumo executivo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq

Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy