Resumo Executivo

Diogo Menezes de Oliveira; Daniele Aparecida Cicillini Pimenta

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

A transição gradual de sistemas monolíticos para arquiteturas de microserviços representa uma mudança de paradigma fundamental na engenharia de software contemporânea, impulsionada pela necessidade de maior agilidade, escalabilidade e modularidade. Em um sistema monolítico, todas as funcionalidades residem em uma única base de código, o que frequentemente resulta em dificuldades para a manutenção e evolução tecnológica, além de criar gargalos de escalabilidade vertical. Em contrapartida, a arquitetura de microserviços propõe a divisão do sistema em aplicações independentes e autônomas, cada uma dedicada a um domínio de negócio específico (Pahl e Jamshidi, 2018). Essa abordagem permite que diferentes equipes trabalhem de forma isolada, utilizando tecnologias mais adequadas para cada problema, mas introduz o desafio crítico da comunicação entre esses componentes distribuídos. Quando uma organização migra para esse modelo, é comum que os serviços inicialmente compartilhem recursos, como camadas de persistência de dados, o que pode gerar interferências e inconsistências se não houver um gerenciamento rigoroso (Dragojevic et al., 2021). Para mitigar tais riscos, a adoção de interfaces de programação de aplicações, conhecidas como API, torna-se essencial para estabelecer contratos claros e rígidos, garantindo que a integridade dos dados seja mantida sem que mudanças internas em um serviço interrompam o funcionamento dos demais (Dragoni et al., 2017).

Dentro desse ecossistema distribuído, a escolha do protocolo de comunicação exerce um impacto direto no desempenho global da aplicação. O formato JavaScript Object Notation, amplamente conhecido como JSON, consolidou-se como o padrão de fato para a troca de dados devido à sua simplicidade e legibilidade por seres humanos. No entanto, por ser um formato baseado em texto, o JSON tende a introduzir uma sobrecarga significativa em comunicações de alta frequência, especialmente em sistemas distribuídos complexos (Rahman e Shatnawi, 2020). Como alternativa, surgiram formatos binários mais compactos e eficientes, como o utilizado pelo protocolo gRPC, que prometem otimizar a troca de informações ao reduzir o tamanho das mensagens e o custo computacional de processamento (Viotti e Kinderkhedia, 2022). Essa necessidade de alta performance é particularmente vital no setor de e-commerce, onde a experiência do usuário é diretamente afetada pela velocidade de carregamento das páginas. Evidências indicam que atrasos superiores a três segundos podem elevar drasticamente as taxas de abandono de carrinhos, impactando a conversão e a fidelização (Google, 2018). A percepção de qualidade técnica por parte do consumidor influencia não apenas a conclusão da compra imediata, mas a confiança de longo prazo na plataforma (PwC, 2024). Portanto, identificar estratégias que minimizem a latência acumulada na agregação de múltiplos microserviços é um objetivo central para garantir a viabilidade técnica e comercial de sistemas modernos de larga escala.

Para avaliar o desempenho e a performance na comunicação de dados, conduziu-se uma pesquisa exploratória baseada em três estudos de caso distintos, focados exclusivamente no processamento de backend para isolar os efeitos da rede e dos protocolos. O cenário simulado consistiu na resposta de uma página de produto de um e-commerce, onde um serviço agregador, seguindo o padrão Backend For Frontend, foi responsável por reunir informações de diversos microserviços de domínio. O processo operacional envolveu a consulta inicial ao microserviço de produtos para obter os identificadores básicos e, subsequentemente, a realização de chamadas paralelas para os domínios de marcas, categorias, imagens e vendedores. O microserviço de marcas forneceu dados como identificação, nome, descrição detalhada, país de origem e o estado de ativação da marca. O domínio de categorias disponibilizou a identificação e o nome da categoria vinculada, enquanto o serviço de imagens retornou identificadores e endereços URL específicos. O microserviço de vendedores entregou o nome e a identificação do lojista responsável. Por fim, o microserviço de produtos centralizou o preço, o nome formatado para URL e as listas de identificadores que permitiram a correlação entre todos os dados. Essa estrutura de agregação permitiu manter a mesma lógica de negócio e o mesmo volume de dados em todos os cenários testados, garantindo a comparabilidade rigorosa entre as abordagens de comunicação (Dragoni et al., 2017).

A implementação técnica de todos os serviços foi realizada utilizando a linguagem de programação Go, escolhida por ser uma linguagem compilada, de tipagem estática e com suporte nativo robusto para concorrência por meio de goroutines, o que facilita a construção de sistemas distribuídos de alto desempenho (The Go Programming Language, 2024). O ambiente de execução foi padronizado utilizando a plataforma Docker, garantindo que cada microserviço operasse em contêineres isolados dentro do sistema operacional. O ambiente local de testes foi configurado em um computador com processador Intel Core i7-8565U de 1.80 GHz, dispondo de 8,0 GB de memória RAM e armazenamento em unidade de estado sólido. Para os contêineres, foram alocados globalmente oito núcleos de processamento e 3.75 GB de memória. A utilização de contêineres permitiu a repetição dos experimentos sob condições controladas, minimizando a interferência de processos externos e assegurando a confiabilidade dos resultados coletados (Neelapu, 2024). O fluxo de testes foi orquestrado pela ferramenta k6, que simulou o acesso simultâneo de 50 usuários virtuais durante o período de um minuto para cada rodada de teste. Para evitar padrões repetitivos que pudessem enviesar a análise, a seleção dos produtos em cada requisição foi feita de forma aleatória, simulando o comportamento real de navegação em uma plataforma de vendas.

O monitoramento do ambiente foi realizado de forma minuciosa, utilizando ferramentas como Telegraf, Prometheus e Grafana para a coleta e visualização de métricas de infraestrutura. Foram registrados o consumo de CPU, expresso em núcleos processados, e a taxa de tráfego de rede, medida em megabytes por segundo para entrada e saída de dados. No âmbito da aplicação, as métricas principais incluíram a taxa de requisições por segundo, que indica a capacidade de vazão do sistema, e a latência medida em milissegundos. A latência foi analisada sob três perspectivas: o valor mínimo, que representa o limite inferior em condições ideais; a média aritmética, que reflete a agilidade percebida pela maioria dos usuários; e o 90º percentil. Este último indicador é crucial, pois mostra o tempo abaixo do qual 90% das requisições foram atendidas, reduzindo a influência de valores atípicos e oferecendo uma visão mais realista da estabilidade do sistema sob carga (Neelapu, 2024). A padronização desses procedimentos permitiu uma análise comparativa profunda entre o uso de JSON sobre HTTP/1.1, MessagePack sobre HTTP/1.1 e o protocolo gRPC operando sobre HTTP/2 com Protocol Buffers.

Nos testes realizados com a abordagem baseada em JSON, observou-se que o formato, embora amplamente compatível, apresentou limitações intrínsecas devido à sua natureza textual. Na terceira rodada de testes, que apresentou os resultados mais estáveis, a taxa de requisições atingiu 2175,67 unidades por segundo. A latência média registrada foi de 22,61 ms, enquanto o 90º percentil ficou em 34,76 ms. O consumo de CPU durante esse processo foi de 2,05 núcleos, e o tráfego de rede transmitido alcançou 3,21 MB/s. Esses dados evidenciam que o processo de serialização e desserialização de texto exige um esforço computacional considerável, o que se traduz em maior latência e consumo de recursos quando o volume de requisições aumenta. Embora o JSON tenha apresentado uma latência mínima competitiva de 2,06 ms, essa vantagem inicial não se sustentou sob carga intensa, demonstrando uma variabilidade significativa que pode comprometer a previsibilidade do sistema em cenários de alta demanda (Google Cloud, 2024).

A segunda abordagem utilizou o MessagePack, um formato binário projetado para ser mais compacto que o JSON, mantendo a compatibilidade com o protocolo HTTP/1.1. Os resultados na terceira tentativa mostraram uma taxa de 1925,18 requisições por segundo, com uma latência média de 25,56 ms e um 90º percentil de 39,88 ms. O consumo de CPU foi ligeiramente inferior, situando-se em 1,93 núcleos, e a rede transmitida foi de 3,22 MB/s. A principal característica notada foi a redução no tamanho das mensagens trafegadas, o que teoricamente deveria favorecer o tempo de resposta. No entanto, a eficiência do MessagePack foi limitada pela manutenção do protocolo de transporte HTTP/1.1, que não oferece os mesmos recursos de multiplexação e otimização de cabeçalhos encontrados em versões mais recentes. Além disso, a utilização desse protocolo exigiu maior cuidado na instrumentação, uma vez que o formato binário não é legível diretamente, dificultando processos de depuração durante o desenvolvimento.

O desempenho superior foi alcançado com a utilização do protocolo gRPC. Na terceira rodada de testes, o sistema processou 2899,58 requisições por segundo, representando um aumento expressivo na capacidade de vazão em comparação às abordagens anteriores. A latência média foi reduzida para 16,97 ms, e o 90º percentil manteve-se estável em 23,31 ms. O consumo de CPU foi o mais eficiente entre todos os cenários, utilizando apenas 1,80 núcleos, enquanto o tráfego de rede transmitido foi de 2,6 MB/s. Essa eficiência é atribuída ao uso do Protocol Buffers para a serialização binária, que gera pacotes de dados significativamente menores e mais rápidos de processar do que o texto puro. Além disso, a integração nativa com o HTTP/2 permite que múltiplas requisições sejam enviadas pelo mesmo canal de comunicação de forma concorrente, eliminando a necessidade de abrir novas conexões para cada chamada entre microserviços. Estudos indicam que o gRPC supera o JSON em desempenho médio justamente pela redução da sobrecarga de leitura e pelo tamanho reduzido do pacote de dados (Rahman e Shatnawi, 2020).

A análise comparativa detalhada revela que, embora o JSON apresente respostas rápidas em condições de baixa concorrência devido à simplicidade de sua estrutura, ele perde eficiência à medida que a carga aumenta. Protocolos baseados em texto possuem um custo de conversão que cresce proporcionalmente ao número de usuários simultâneos, o que reduz a vantagem inicial de latência mínima (Google Cloud, 2024). O gRPC, por outro lado, demonstrou maior previsibilidade e menor dispersão entre as respostas rápidas e lentas, o que é uma característica crítica para sistemas de e-commerce que dependem de uma experiência de navegação fluida. A capacidade do gRPC de processar um volume maior de requisições com menor consumo de CPU reflete sua adequação para cenários de alta escalabilidade, reduzindo o overhead em chamadas curtas e frequentes que são típicas em arquiteturas de microserviços (Viotti e Kinderkhedia, 2022). O menor volume de dados trafegados na rede pelo gRPC também sugere uma economia de banda que, em ambientes de nuvem, pode resultar em redução de custos operacionais.

A eficiência observada no consumo de CPU pelo gRPC é consistente com pesquisas que apontam as vantagens de formatos binários pré-compilados, que exigem menos ciclos de processamento para serem interpretados pela linguagem de programação (Dragojevic et al., 2021). Enquanto o JSON exigiu mais recursos para realizar conversões de texto para estruturas de dados internas, o gRPC aproveitou a estrutura binária otimizada do Protocol Buffers para acelerar essa transição. No que diz respeito ao tráfego de rede, o JSON foi responsável pelos maiores volumes de dados devido à verbosidade do formato textual, enquanto o gRPC combinou pacotes compactos com a eficiência do transporte via HTTP/2. Essa combinação resultou em uma solução que não apenas responde mais rápido ao usuário final, mas também sobrecarrega menos a infraestrutura de servidores e rede.

Apesar dos resultados positivos, é necessário reconhecer as limitações do estudo realizado. Os experimentos foram conduzidos em um ambiente local controlado e em uma máquina com configurações de hardware intermediárias, sem o uso de infraestrutura dedicada em nuvem ou ferramentas de orquestração complexas como o Kubernetes. Tais fatores restringem a avaliação da escalabilidade em cenários de distribuição geográfica ou condições adversas de rede, como alta perda de pacotes ou latência de conexão variável. Além disso, o estudo focou em uma única linguagem de programação, não explorando como a interoperabilidade entre diferentes linguagens poderia afetar o desempenho do gRPC ou do MessagePack. Pesquisas futuras poderiam expandir essa análise para ambientes de nuvem pública, avaliando o impacto de latências de rede reais e o comportamento dos protocolos em sistemas com centenas de microserviços interconectados.

Conclui-se que o objetivo foi atingido, uma vez que a comparação entre os protocolos demonstrou de forma quantitativa a superioridade do gRPC na redução da latência e na otimização do uso de recursos de hardware. A solução baseada em gRPC proporcionou uma redução de 24,9% no tempo médio de resposta em relação ao padrão JSON, além de suportar uma taxa de requisições significativamente superior com menor consumo de CPU e banda de rede. Esses resultados confirmam que a adoção de protocolos de comunicação binários, aliados a transportes modernos como o HTTP/2, é uma estratégia altamente eficaz para mitigar os desafios de performance inerentes às arquiteturas de microserviços em plataformas de e-commerce. A implementação de contratos rígidos e a serialização eficiente mostram-se fundamentais para garantir a escalabilidade e a estabilidade necessárias para suportar altas demandas de acesso, atendendo aos requisitos técnicos e de negócio exigidos pelo mercado atual.

Referências Bibliográficas:

DRAGOJEVIC, Aleksandar; KOSMIDER, Krzysztof; ZHANG, Ding. Performance of JSON, Protobuf, and gRPC for Microservices Communication. IEEE Access, v. 9, p. 118–128, 2021.

DRAGONI, Nicola et al. Microservices: Yesterday, Today, and Tomorrow. In: Present and Ulterior Software Engineering. Springer, 2017. p. 195–216.

GOOGLE CLOUD. Refatoração de monolitos em microsserviços. 2024. Disponível em: <https://cloud.google.com/architecture/microservices-architecture-refactoring-monoliths/>. Acesso em: 12 mar. 2024.

GOOGLE. Think with Google – Performance Matters. 2018. Disponível em: <https://www.thinkwithgoogle.com/intl/en-cee/consumer-insights/consumer-trends/performance-matters/>. Acesso em: 12 mar. 2024.

NEELAPU, M. The effectiveness of load and performance testing on application scalability. ESP Journal of Engineering & Technology Advancements, v. 4, n. 3, p. 171–180, 2024.

PAHL, Claus; JAMSHIDI, Pooyan. Microservices: A Systematic Mapping Study. Journal of Systems and Software, v. 137, p. 48–61, 2018.

PWC. Customer experience is everything. 2024. Disponível em: <https://www.pwc.com/us/en/services/consulting/library/consumer-intelligence-series/future-of-customer-experience.html/>. Acesso em: 14 ago. 2025.

RAHMAN, M.; SHATNAWI, A. M. Performance comparison of gRPC and REST for microservices based applications. International Journal of Advanced Computer Science and Applications, v. 11, n. 2, p. 605–614, 2020.

The Go Programming Language. About Go. 2024. Disponível em: <https://go.dev/ref/spec/>. Acesso em: 14 jun. 2025.

VIOTTI, Paolo; KINDERKHEDIA, Samir. An Experimental Comparison of REST and gRPC for Microservices Communication. In: IEEE/ACM International Symposium on Software Engineering for Adaptive and Self-Managing Systems (SEAMS), 2022.

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