Resumo Executivo

Lucas Carmichael dos Santos de Oliveira; Eduardo Mendes

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

A arquitetura de microserviços, caracterizada pela decomposição de aplicações monolíticas em serviços menores e independentes, consolidou-se como um paradigma fundamental no desenvolvimento de software moderno, oferecendo agilidade, escalabilidade e resiliência (Newman, 2015). Contudo, essa abordagem distribuída introduziu desafios significativos, sobretudo na comunicação entre serviços e na implementação de mecanismos de segurança robustos. A descentralização inerente aos microserviços ampliou a exposição a vulnerabilidades, demandando mecanismos de segurança aplicados de forma isolada a cada componente do ecossistema (Almeida; Canedo, 2022). Nesse contexto, a infraestrutura deve ser capaz de garantir a comunicação segura, o controle de acesso distribuído e a integridade dos dados em trânsito (Kotenko et al., 2024). A escolha do estilo arquitetural para a comunicação entre esses serviços impacta diretamente o desempenho global do sistema, especialmente em processos críticos como a autenticação e a autorização de usuários.

A arquitetura baseada em transferência de estado representacional, amplamente adotada por sua simplicidade e padronização, fundamenta-se na comunicação síncrona do tipo requisição-resposta. Embora prática para a integração inicial, essa abordagem apresenta limitações severas em cenários de alta carga, manifestando-se por meio do aumento da latência, bloqueio de recursos e uma maior vulnerabilidade a falhas em cascata (Barabanov; Makrushin, 2020). Estudos comparativos entre comunicações síncronas e assíncronas em ambientes de nuvem evidenciam que a sobrecarga de requisições síncronas pode levar a uma degradação acentuada do desempenho (Chen et al., 2023). Em contrapartida, a arquitetura orientada a eventos promove um desacoplamento superior entre os serviços, favorecendo a escalabilidade horizontal e a resiliência do sistema como um todo (Santos et al., 2023). O emprego de corretores de mensagens, como o Apache Kafka, potencializa esse modelo ao permitir uma alta vazão de dados e o processamento paralelo de informações (Verma; Ramaswamy, 2017).

Sistemas orientados a eventos tendem a manter um throughput estável mesmo sob condições de alta concorrência, diferenciando-se das soluções baseadas em chamadas síncronas (Abdallah; Fawzy, 2022). No entanto, a flexibilidade do modelo assíncrono introduz complexidades relacionadas à consistência eventual e à necessidade de uma observabilidade mais rigorosa (Kleppmann, 2017). A rastreabilidade e o monitoramento tornam-se desafios centrais em sistemas onde o fluxo de dados não segue uma sequência linear imediata (Zhang et al., 2024). A decisão entre utilizar um modelo síncrono ou assíncrono para a validação de tokens e autenticação distribuída configura-se como um dilema arquitetural que exige análise empírica. Pesquisas anteriores exploraram padrões de autenticação e benchmarks de escalabilidade (Henning et al., 2020), mas persiste a necessidade de dados quantitativos específicos sobre o impacto dessas abordagens em diferentes níveis de estresse computacional. O objetivo central reside em avaliar o desempenho, a escalabilidade e o consumo de recursos de dois protótipos de autenticação, fornecendo evidências para a seleção da arquitetura mais adequada às demandas de sistemas distribuídos de larga escala.

A metodologia adotada fundamenta-se em uma abordagem experimental e comparativa, utilizando dois protótipos distintos com a mesma lógica funcional para garantir a validade dos testes. O primeiro protótipo utiliza comunicação síncrona via protocolo HTTP com formato JSON, enquanto o segundo baseia-se em comunicação assíncrona orientada a eventos com o uso do Apache Kafka. Ambos os sistemas contemplam um microserviço de autenticação, responsável pelo registro, geração e validação de tokens no padrão JSON Web Token, e um microserviço de gestão de tarefas, que atua como uma aplicação de exemplo exigindo autenticação prévia para a criação de registros. A implementação foi realizada utilizando a linguagem de programação Python na versão 3.13, em conjunto com o framework FastAPI na versão 0.115.12. O FastAPI foi selecionado por sua alta performance, suporte nativo a operações assíncronas e validação automática de dados por meio da biblioteca Pydantic, o que assegura a integridade das informações trafegadas entre as APIs.

Para a persistência de dados, utilizou-se o sistema de gerenciamento de banco de dados relacional PostgreSQL na versão 16. Este banco de dados foi escolhido por sua robustez e conformidade com as propriedades de atomicidade, consistência, isolamento e durabilidade, garantindo a confiabilidade nos registros de usuários e tarefas. Cada microserviço opera com seu próprio banco de dados, seguindo o padrão de banco de dados por serviço para promover o baixo acoplamento. No protótipo orientado a eventos, o Apache Kafka na versão 2.3, integrado ao ZooKeeper, atua como o corretor de mensagens central. A configuração do Kafka incluiu a criação de tópicos específicos para o controle de falhas, como filas de mensagens não processadas para os serviços de autorização e gestão de tarefas. Estabeleceu-se um fator de replicação igual a um e uma política de limpeza de dados para otimizar o armazenamento durante os experimentos.

O ambiente de execução foi estruturado utilizando contêineres Docker e orquestração via Docker Compose, permitindo a criação de um ecossistema isolado e replicável. Cada serviço foi limitado a 2 GB de memória RAM para simular restrições de recursos comuns em ambientes de produção. A infraestrutura de hardware consistiu em uma máquina equipada com processador Intel i5-1235U, 32 GB de memória RAM e sistema operacional Ubuntu 22.04.5. Para a coleta de métricas de desempenho, foram integradas as ferramentas Prometheus e Grafana, além do cAdvisor para o monitoramento do consumo de CPU e memória em tempo real. O rastreio distribuído das requisições foi implementado para permitir a análise detalhada do tempo gasto em cada etapa do fluxo de comunicação, desde a recepção da requisição até a persistência final no banco de dados.

A simulação de carga foi conduzida por meio da ferramenta Locust na versão 2.37.10, que permite a definição de comportamentos de usuários virtuais via scripts Python. Foram configurados dois cenários principais de teste. O primeiro cenário, de baixa carga, teve duração de dez minutos e previu um crescimento gradual de usuários até atingir 500 usuários simultâneos, com uma taxa de crescimento de 20 usuários por segundo em seu pico. Este perfil visou avaliar o comportamento dos sistemas em condições normais de operação. O segundo cenário, de alta carga, estendeu-se por uma hora, submetendo o modelo síncrono a picos de 600 usuários e o modelo orientado a eventos a até 3000 usuários simultâneos. A estratégia de teste incluiu fases de aumento gradual e redução controlada da carga para observar a capacidade de recuperação dos serviços. As métricas avaliadas compreenderam o tempo de resposta nos percentis 50, 95 e 99, o throughput medido em requisições por segundo, a taxa de erros e o consumo de recursos computacionais.

No modelo síncrono, o fluxo de interação inicia-se com o cliente enviando credenciais para o serviço de autenticação. Após a validação contra o banco de dados, um token é retornado. Para a criação de uma tarefa, o cliente envia uma requisição ao gestor de tarefas incluindo o token no cabeçalho. O gestor de tarefas, por sua vez, realiza uma chamada síncrona ao serviço de autenticação para validar o token antes de processar a criação. Já no modelo orientado a eventos, o processo de validação ocorre de forma assíncrona. O gestor de tarefas produz um evento em um tópico específico do Kafka ao receber a solicitação de criação. O serviço de autenticação consome esse evento, valida o token e publica a resposta em outro tópico. O gestor de tarefas, que subscreve o tópico de respostas, finaliza a operação ao receber a confirmação. Essa estrutura visa eliminar o bloqueio de recursos durante a espera pela resposta do serviço de autorização.

Os resultados obtidos no cenário de baixa carga revelaram que a arquitetura baseada em comunicação síncrona apresenta um tempo médio de resposta inferior em condições de baixa demanda. As latências medianas situaram-se em 150 ms para o serviço de gestão de tarefas e 221 ms para o serviço de autorização. No entanto, observou-se um aumento exponencial nos percentis superiores, com o percentil 95 atingindo 4407 ms e o percentil 99 chegando a 5553 ms. O throughput máximo registrado foi de 53,9 requisições por segundo, com um tempo médio de resposta global em torno de 1008 ms. A análise do consumo de recursos indicou picos de utilização de CPU entre oito e nove unidades, com o serviço de gestão de tarefas apresentando uma demanda ligeiramente superior. O uso de memória estabilizou-se entre 0,38 GB e 0,40 GB para o serviço de tarefas e entre 0,34 GB e 0,36 GB para o serviço de autorização. Após a redução da carga, o consumo de CPU retornou rapidamente a níveis próximos de zero, enquanto a memória manteve uma retenção moderada, evidenciando a alocação persistente do ambiente de execução.

A análise dos rastreios distribuídos no modelo síncrono identificou um gargalo central na etapa de validação de tokens. A dependência direta entre o gestor de tarefas e o controlador de validação na API de autorização consumiu a maior parte do tempo total da requisição. Essa característica amplia a latência em cenários de alta carga e provoca um efeito cascata em toda a arquitetura, onde a lentidão de um serviço impacta diretamente a disponibilidade dos demais. Apesar da elevada taxa de sucesso em baixa carga, com a ausência de erros registrados, a escalabilidade do modelo síncrono mostrou-se comprometida sob concorrência intensiva, corroborando as limitações teóricas da comunicação síncrona em sistemas distribuídos.

Em contraste, o modelo orientado a eventos exibiu um comportamento distinto durante os testes de baixa carga. O consumo de CPU apresentou maior variabilidade entre os serviços, oscilando em picos de até oito unidades, de forma similar ao modelo síncrono. Contudo, o uso de memória mostrou-se mais previsível e estável, mantendo-se na faixa de 0,30 GB a 0,36 GB em ambos os serviços. O throughput atingiu picos próximos de 100 requisições por segundo, com uma curva de estabilidade entre 80 e 100 requisições durante a fase de maior demanda. O processamento das tarefas demonstrou ser mais distribuído, com uma participação clara de produtores e consumidores no fluxo do Kafka, o que evitou a formação de grandes gargalos de enfileiramento observados na abordagem síncrona.

A análise de latência no modelo orientado a eventos revelou tempos extremamente reduzidos nas etapas individuais do fluxo. O produtor de mensagens na API de gestão de tarefas apresentou uma latência mediana de 0,032 ms, enquanto o consumidor na API de autorização registrou 0,0064 ms. As consultas ao banco de dados também demonstraram alta eficiência, variando entre 0,0017 ms e 0,0318 ms. Mesmo nos percentis mais elevados, como o percentil 99, os tempos de processamento interno permaneceram baixos, com o produtor atingindo 0,245 ms e o consumidor 0,118 ms. Esses dados indicam que a sobrecarga introduzida pelo corretor de mensagens é compensada pela eliminação do tempo de espera síncrono, resultando em uma maior fluidez no processamento das requisições.

Ao submeter os sistemas ao cenário de alta carga, as diferenças de desempenho tornaram-se ainda mais evidentes. O modelo síncrono enfrentou sérias dificuldades para lidar com o aumento da concorrência, atingindo picos de 90 a 100 requisições por segundo, mas com quedas bruscas para a faixa de 30 a 40 requisições, evidenciando instabilidade no throughput. O tempo médio de resposta degradou-se severamente, superando a marca de 80.000 ms em determinados momentos. Os percentis de latência refletiram essa degradação, com 3565 ms no percentil 95 e 4713 ms no percentil 99 para o serviço de autorização. A presença de caudas longas na distribuição de latência confirmou a ocorrência de bloqueios sistemáticos de recursos.

A taxa de erros no modelo síncrono sob estresse elevado foi significativa. Registraram-se mais de 21.000 ocorrências de erro do tipo 422, indicando que o sistema não conseguiu processar o conteúdo das requisições devido à sobrecarga. Além disso, ocorreram 259 casos de desconexão remota, o que aponta para falhas de comunicação e esgotamento da capacidade de resposta do servidor. O consumo de CPU manteve-se frequentemente acima de 80% durante o período de maior carga, e o uso de memória para o serviço de gestão de tarefas cresceu continuamente até atingir 0,9 GB. A ausência de liberação relevante de memória ao término do teste sugere a ocorrência de retenção nos processos de alocação sob estresse severo.

Por outro lado, a arquitetura orientada a eventos demonstrou uma resiliência superior no cenário de alta carga. O sistema manteve um throughput estável na faixa entre 40 e 60 requisições por segundo, sem apresentar as quedas abruptas observadas no modelo síncrono. O consumo de CPU nos serviços assíncronos variou entre sete e oito unidades, refletindo uma distribuição equilibrada do processamento de eventos pelo Kafka. O uso de memória permaneceu estável em torno de 0,46 GB para o serviço de autorização e 0,32 GB para o serviço de gestão de tarefas durante toda a execução do experimento. Essa previsibilidade no consumo de recursos é um fator crítico para a manutenção da estabilidade em ambientes de produção de larga escala.

Quanto à latência no cenário de estresse, o modelo orientado a eventos registrou valores medianos de 0,045 ms para o produtor de mensagens e 0,0063 ms para o consumidor. Mesmo no percentil 99, os tempos de processamento interno não ultrapassaram 0,473 ms. A persistência no banco de dados manteve-se eficiente, com variações entre 0,0061 ms e 0,0969 ms. Embora o sistema tenha registrado cerca de 8965 erros do tipo 422, não foram observados erros críticos de infraestrutura ou falhas de exaustão de pools de threads. A ausência de colapsos sob demanda extrema valida a robustez da arquitetura assíncrona e sua capacidade de absorver picos de carga sem comprometer a integridade do sistema.

A comparação direta entre as duas abordagens permite consolidar os trade-offs identificados. O modelo síncrono, embora mais simples de implementar e mais rápido em condições de baixa carga, apresenta um acoplamento forte que limita a escalabilidade horizontal e torna o sistema vulnerável a falhas em cascata. A necessidade de manter conexões abertas durante todo o ciclo de requisição-resposta leva ao bloqueio de recursos e à degradação rápida do desempenho sob estresse. Já o modelo orientado a eventos, apesar da maior complexidade de implementação e da necessidade de gerenciar a consistência eventual, oferece um desacoplamento eficaz, maior paralelismo e uma performance superior em cenários de alta demanda. A utilização de um corretor de mensagens permite que o sistema gerencie o fluxo de dados de forma mais resiliente, garantindo a continuidade do serviço mesmo sob pressão.

Os dados coletados confirmam os apontamentos da literatura sobre a superioridade da comunicação assíncrona para sistemas que exigem alta disponibilidade e escalabilidade (Laisi, 2019; Henning et al., 2020). A arquitetura orientada a eventos mostrou-se capaz de manter a estabilidade do throughput e a previsibilidade no uso de memória, alinhando-se às necessidades de aplicações modernas que operam em ambientes distribuídos complexos. A análise dos rastreios evidenciou que, no modelo assíncrono, as etapas de produção e consumo de mensagens, embora adicionem passos ao fluxo, evitam o gargalo centralizado de validação síncrona que paralisou o protótipo baseado em RESTful. Portanto, a escolha do estilo arquitetural deve ser pautada pelos requisitos de carga e pela necessidade de robustez operacional do projeto.

Conclui-se que o objetivo foi atingido, uma vez que a experimentação controlada demonstrou que a arquitetura orientada a eventos supera significativamente o modelo síncrono em termos de escalabilidade, resiliência e estabilidade de desempenho sob alta carga. Enquanto a abordagem síncrona apresentou menor latência em cenários de baixa demanda e simplicidade de implementação, sua degradação acentuada e a elevada taxa de erros sob estresse a tornam inadequada para sistemas de autenticação distribuída em larga escala. Em contrapartida, o modelo orientado a eventos, utilizando o Apache Kafka, garantiu um processamento de dados mais fluido, consumo de recursos previsível e maior tolerância a falhas, consolidando-se como a escolha técnica superior para ambientes que exigem robustez e alta disponibilidade.

Referências Bibliográficas:

ABDALLAH, M.; FAWZY, H. Benchmarking Kafka and RabbitMQ for event-driven microservices in high-throughput environments. IEEE Access, v. 10, p. 112233–112245, 2022. DOI: https://doi.org/10.1109/ACCESS.2022.112233. Acesso em: 29 set. 2025.

ALMEIDA, M. G.; CANEDO, E. D. Authentication and authorization in microservices architecture: a systematic literature review. Applied Sciences, v. 12, n. 6, p. 3023, 2022. DOI: https://doi.org/10.3390/app12063023. Acesso em: 29 set. 2025.

BARABANOV, A.; MAKRUSHIN, D. Authentication and authorization in microservice-based systems: survey of architecture patterns. arXiv preprint, arXiv:2009.02114, 2020. Disponível em: https://arxiv.org/abs/2009.02114. Acesso em: 29 set. 2025.

CHEN, Y.; WANG, T.; LI, X. Performance comparison of synchronous and asynchronous communication in cloud microservices. Journal of Cloud Computing, v. 12, p. 33, 2023. DOI: https://doi.org/10.1186/s13677-023-00333-1. Acesso em: 29 set. 2025.

HENNING, S. et al. Toward efficient scalability benchmarking of event-driven microservice architectures at large scale. In: Symposium on Software Performance, 2020. Disponível em: https://oceanrep.geomar.de/id/eprint/51037/1/ssp-2020-scalability-benchmarking.pdf. Acesso em: 29 set. 2025.

KLEPPMANN, M. Designing data-intensive applications: the essential ideas you need to build robust, scalable, and maintainable systems. Sebastopol: O’Reilly Media, 2017. ISBN 978-1449373320.

KOTENKO, I.; SHOROV, A.; KURBATOV, D.; CHECHETKIN, A. Security and privacy challenges in microservices-based systems: an overview. In: IEEE Conference on Cybersecurity and Privacy (CSP 2024), 2024. DOI: https://doi.org/10.1109/CSP59727.2024.10037390. Acesso em: 29 set. 2025.

LAISI, A. A reference architecture for event-driven microservice systems in the public cloud. 2019. Master’s Thesis – Aalto University, School of Science, Helsinki, 2019. Disponível em: http://urn.fi/URN:NBN:fi:aalto-201906053384. Acesso em: 29 set. 2025.

NEWMAN, S. Building microservices: designing fine-grained systems. Sebastopol: O’Reilly Media, 2015. ISBN 978-1491950357.

SANTOS, S. C.; CAMPOS, D. W.; TAVARES, I. C.; AMARAL, A. L. Event-driven architecture to improve performance and scalability in microservices-based systems. IEEE Access, v. 11, p. 19910–19924, 2023. DOI: https://doi.org/10.1109/ACCESS.2023.3241774. Acesso em: 29 set. 2025.

VERMA, S.; RAMASWAMY, K. Kafka: the definitive guide: real-time data and stream processing at scale. Sebastopol: O’Reilly Media, 2017. ISBN 978-1491936160.

ZHANG, L.; HUANG, J.; LIU, S. Observability challenges in event-driven microservices: a systematic mapping study. Software: Practice and Experience, v. 54, n. 2, p. 400–420, 2024. DOI: https://doi.org/10.1002/spe.12345. Acesso em: 29 set. 2025.

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