Vitor da Conceição Rosas da Silva; Alexandre Leite Rangel

DOI: 10.22167/2675-6528-202601509

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

Resumo

A transição da engenharia de software para ambientes distribuídos com microsserviços impôs desafios complexos na comunicação entre serviços e na tomada de decisões arquiteturais. O presente trabalho analisou comparativamente arquiteturas monolíticas e baseadas em microsserviços, com o objetivo de identificar os fatores que orientam a adoção de cada modelo e seus impactos na escalabilidade, manutenibilidade e eficiência operacional. Para isso, adotou-se uma abordagem mista, que combinou um levantamento de percepções com 21 profissionais de tecnologia e o desenvolvimento de um protótipo funcional de e-commerce. O protótipo, implementado em Python com FastAPI, PostgreSQL e RabbitMQ, simulou um sistema de e-commerce com seis microsserviços e permitiu comparar empiricamente padrões de comunicação síncrona (REST/HTTP) e assíncrona (RabbitMQ com padrão Saga) em cenários controlados. Métricas de latência (p50, p95, p99), throughput e taxa de erros foram coletadas e monitoradas com Prometheus, Grafana e Jaeger. Os resultados da pesquisa com profissionais revelaram a predominância de arquiteturas híbridas (47,6%) e indicaram que a escolha do modelo de comunicação depende do tipo de operação (76,2%). A análise de desempenho do protótipo demonstrou que a comunicação assíncrona resultou em menor latência percebida pelo usuário (P50 de 85 ms vs. 450 ms no síncrono) e maior throughput (45,2 req/s vs. 12,5 req/s) em operações complexas como checkout, enquanto a comunicação síncrona proporcionou confirmação imediata de transações. Concluiu-se que a decisão arquitetural deve considerar a complexidade do domínio, a necessidade de escalabilidade e a maturidade da equipe, sendo a implementação de observabilidade robusta fundamental para a operação de sistemas distribuídos.

Palavras-chave: Arquitetura de software; Comunicação assíncrona; E-commerce; Escalabilidade; Observabilidade.

1. Introdução

A engenharia de software tem testemunhado uma evolução paradigmática nas últimas décadas, transitando de sistemas centralizados e arquiteturas monolíticas para ambientes distribuídos, caracterizados por múltiplos serviços e dependências tecnológicas de crescente complexidade (Sommerville, 2007). Essa transformação é impulsionada por um aumento exponencial no volume de dados a serem processados, pela necessidade de integrações mais diversas entre sistemas e por uma demanda contínua por escalabilidade e resiliência nas aplicações corporativas (Fowler; Lewis, 2014). Nesse cenário dinâmico, arquiteturas baseadas em microsserviços, juntamente com a adoção de padrões de comunicação assíncrona e a implementação de mecanismos robustos de observabilidade, emergiram como respostas eficazes para alcançar ganhos significativos em escalabilidade e resiliência, embora introduzam uma complexidade operacional inerente (Newman, 2019).

No contexto do desenvolvimento de software contemporâneo, a escolha arquitetural não se alinha a uma solução universalmente aplicável, mas sim a abordagens que se adequam a cenários específicos de negócio e técnicos (Newman, 2021). A decisão entre uma arquitetura monolítica e uma baseada em microsserviços é multifacetada, influenciada por fatores como o domínio do negócio, a experiência e maturidade da equipe de desenvolvimento, e os requisitos estratégicos da organização. Richardson (2018) enfatiza que a transição para microsserviços deve ser uma escolha deliberada e estratégica, fundamentada em necessidades genuínas de escalabilidade, autonomia de equipes e agilidade na entrega de valor, e não meramente uma adesão a tendências tecnológicas. Sem uma arquitetura bem definida, as equipes podem desenvolver soluções desorganizadas, resultando em código distribuído de forma caótica, o que eleva a complexidade e dificulta a manutenção e a evolução do sistema (Fowler; Lewis, 2014). Bass et al. (2021) reforçam que as decisões arquiteturais são, em sua essência, decisões de negócio, impactando diretamente os custos operacionais, a velocidade de entrega de novas funcionalidades e a capacidade de adaptação às constantes mudanças do mercado.

A evolução das arquiteturas para modelos distribuídos impulsionou o desenvolvimento e a adoção de mecanismos de comunicação assíncronos, filas de mensagens e ferramentas de observabilidade em larga escala. Microsserviços, ao promoverem a fragmentação de sistemas em componentes menores e independentes, oferecem maior flexibilidade, escalabilidade e distribuição funcional, mas exigem mecanismos sofisticados de comunicação e coordenação (Namiot; Sneps-Sneppe, 2014; Newman, 2021). Por outro lado, arquiteturas monolíticas mantêm sua relevância, especialmente em projetos que priorizam simplicidade de implementação e manutenção inicial, ou em domínios de menor complexidade (Newman, 2019). A garantia de consistência e resiliência em arquiteturas distribuídas, como as baseadas em microsserviços, depende fundamentalmente de sistemas de mensageria e processamento distribuído de dados (Kleppmann, 2017). Além disso, a complexidade inerente a esses sistemas exige uma visibilidade aprofundada de seu comportamento em tempo real, tornando a observabilidade (composta por métricas, logs e traces) um pilar indispensável para a operação e diagnóstico eficazes (Sridharan, 2018).

Diante deste panorama de escolhas arquiteturais complexas e da necessidade de equilibrar benefícios e desafios, torna-se crucial investigar de que maneira as organizações abordam a decisão entre arquiteturas monolíticas e baseadas em microsserviços, e quais critérios técnicos e organizacionais orientam essa escolha. Observa-se uma lacuna na literatura em estudos que combinam a percepção prática de profissionais do mercado com a validação experimental em um ambiente controlado, especialmente no que tange aos padrões de comunicação entre serviços e seus impactos no desempenho. Assim, este trabalho teve como objetivo analisar comparativamente as abordagens arquiteturais monolítica e baseada em microsserviços, buscando identificar os fatores que orientam a adoção de cada modelo e compreender como essas decisões impactam a escalabilidade, a manutenibilidade e a eficiência operacional no longo prazo.

2. Material e Métodos

O presente estudo adotou uma abordagem mista, combinando a coleta de dados primários por meio de um questionário eletrônico com o desenvolvimento de um protótipo funcional para validação experimental. Essa metodologia buscou analisar comparativamente arquiteturas monolíticas e baseadas em microsserviços, investigando critérios técnicos e organizacionais que orientam a escolha de cada modelo. A pesquisa aplicada em engenharia de software, conforme Sommerville (2007), justifica a integração de levantamentos de percepções profissionais com experimentação controlada para validar características práticas das soluções propostas, oferecendo uma visão abrangente dos desafios e benefícios arquiteturais.

A pesquisa foi conduzida em duas frentes complementares. A primeira envolveu um levantamento de dados primários, aplicado a profissionais atuantes nos setores de tecnologia e mercado financeiro no Brasil. A segunda frente consistiu no desenvolvimento de um protótipo funcional de e-commerce, operado em um ambiente controlado para simulações de desempenho. A unidade de análise para o levantamento foram as percepções e práticas de profissionais de software, enquanto para o protótipo, foram os padrões de comunicação síncrona e assíncrona entre microsserviços. O período de coleta de dados e desenvolvimento ocorreu no contexto do ano de 2026, conforme a data de apresentação do trabalho.

A população-alvo para o levantamento compreendeu profissionais com experiência na área de tecnologia, com preferência por aqueles que atuam em ambientes corporativos de diversos portes. A amostra foi composta por vinte e um profissionais, selecionados por conveniência. Os critérios de inclusão focaram na experiência em tecnologia e atuação em empresas de diferentes tamanhos. A distribuição da amostra incluiu participantes de pequenas, médias e grandes empresas, com variados níveis de experiência profissional, desde menos de dois anos até mais de dez anos de atuação no setor. Essa composição visou capturar uma gama diversificada de vivências.

O instrumento de coleta de dados para o levantamento foi um questionário eletrônico, desenvolvido e aplicado por meio da plataforma Google Forms, conforme detalhado no Apêndice A. Este questionário foi estruturado para investigar aspectos cruciais da experiência profissional dos participantes. As perguntas abordaram o porte da empresa, o tempo de experiência em tecnologia, o cargo atual, a arquitetura predominante nos sistemas, as razões para a manutenção de sistemas monolíticos, os motivos para a adoção de microsserviços, os métodos de comunicação entre serviços, as ferramentas de mensageria utilizadas e as práticas de monitoramento adotadas.

Para a validação empírica das hipóteses, desenvolveu-se um protótipo funcional de um sistema de e-commerce, concebido com uma arquitetura de microsserviços. Este protótipo foi projetado para operar com dois modos de comunicação intercambiáveis: síncrono e assíncrono. O desenvolvimento dos microsserviços foi realizado em Python, versão 3.11, empacotado em contêineres Docker. O framework web utilizado foi o FastAPI, versão 0.109.0, e a execução das aplicações foi gerenciada pelo servidor ASGI Uvicorn, versão 0.27.0. Essa configuração permitiu a coleta de métricas de desempenho e latência em cenários distintos.

Para o gerenciamento de dados persistentes, utilizou-se o PostgreSQL, versão 15, com acesso via SQLAlchemy, versão 2.0.25, como ORM. Os drivers AsyncPG, versão 0.29.0, e Psycopg2-binary, versão 2.9.9, foram empregados para operações assíncronas e síncronas, respectivamente. Para cache distribuído e gerenciamento de sessões, integrou-se o Redis, versão 7, com a biblioteca redis-py, versão 5.0.1. A comunicação assíncrona entre os microsserviços foi estabelecida com o RabbitMQ, versão 3.13, configurado para filas de mensagens e o padrão publish/subscribe, utilizando a biblioteca aio-pika, versão 9.3.1. A comunicação síncrona, baseada em chamadas HTTP, empregou a biblioteca HTTPX, versão 0.26.0.

O sistema protótipo foi estruturado em seis microsserviços independentes: catálogo de produtos, carrinho de compras, pedidos, pagamentos, inventário e um API Gateway central, que atuou como ponto único de entrada para as requisições. Cada microsserviço manteve seu próprio esquema de banco de dados no PostgreSQL, aderindo ao princípio de database-per-service (Richardson, 2018). Para assegurar a visibilidade e o monitoramento do comportamento do sistema, implementou-se um conjunto de ferramentas de observabilidade, incluindo Prometheus, versão 2.48.0, para métricas, Grafana, versão 10.2.0, para dashboards, e Jaeger, versão 1.52, para rastreamento distribuído via OpenTelemetry (OTLP).

No modo de comunicação síncrona, o serviço de pedidos atuou como orquestrador central, realizando chamadas HTTP diretas para os demais microsserviços envolvidos no fluxo de checkout. A sequência de processamento para uma operação de checkout envolveu a consulta ao carrinho, a solicitação de reserva de estoque ao serviço de inventário via HTTP POST, o encaminhamento do processamento do pagamento e, por fim, a confirmação da reserva de estoque e a limpeza do carrinho. Em situações de falha em qualquer etapa, o sistema foi projetado para executar transações compensatórias explícitas, como a liberação automática de estoque em caso de falha no pagamento.

Para o modo assíncrono, o sistema implementou o padrão Saga para a orquestração de transações distribuídas (Richardson, 2018). Ao receber uma solicitação de pedido, o serviço de pedidos publicava um evento inicial e retornava uma resposta imediata ao cliente com status pendente. O processamento subsequente ocorria em segundo plano, por meio de workers que consumiam eventos das filas do RabbitMQ. O fluxo de eventos da Saga foi implementado em uma sequência específica: o serviço de pedidos publicava um evento de solicitação de pagamento, um worker de pagamentos processava e publicava o resultado. Em caso de sucesso, o serviço de pedidos solicitava a reserva de estoque, que era processada por um worker de inventário. Se ocorresse falha em qualquer etapa, a Saga entrava em estado de compensação, executando ações reversíveis para restaurar a consistência do sistema, conforme o modelo de consistência eventual (Namiot; Sneps-Sneppe, 2014).

A orquestração da Saga no protótipo envolveu diversos estados, que foram cuidadosamente definidos para gerenciar o ciclo de vida de um pedido, desde sua criação até a conclusão ou a execução de ações compensatórias em caso de falha. A Tabela 1 detalha os estados implementados e suas respectivas descrições, fornecendo uma visão clara do gerenciamento do fluxo de transações distribuídas no ambiente assíncrono.

Tabela 1. Estados da orquestração Saga implementados no protótipo

Estado	Descrição
created	Pedido criado, aguardando início do processamento
payment_requested	Solicitação de pagamento enviada ao serviço de pagamentos
payment_completed	Pagamento confirmado com sucesso
stock_requested	Solicitação de reserva de estoque enviada
completed	Pedido finalizado com sucesso
failed	Pedido falhou em alguma etapa do fluxo
compensating	Executando ações compensatórias de rollback

Fonte: Dados originais da pesquisa

O sistema foi configurado para coletar métricas de desempenho de forma contínua, utilizando o Prometheus. O volume de requisições HTTP foi registrado por meio do contador http_requests_total, com segmentação por serviço, método, endpoint e modo de comunicação. A latência das requisições foi mensurada pela métrica http_request_duration_seconds, que utilizou um histograma com faixas de tempo variando de 5 milissegundos a 10 segundos. Para o modo assíncrono, métricas adicionais específicas do RabbitMQ foram monitoradas, incluindo o total de mensagens publicadas, consumidas e encaminhadas para as Dead Letter Queues (DLQ).

Todas as métricas coletadas, tanto as gerais de HTTP quanto as específicas do RabbitMQ, foram visualizadas em tempo real por meio de um dashboard configurado no Grafana. Este dashboard apresentava painéis comparativos de throughput, latência e taxa de erros entre os modos de comunicação síncrono e assíncrono. Os testes de carga para o protótipo foram executados utilizando a ferramenta Locust, simulando a atuação de cinquenta usuários concorrentes, com cada modo de comunicação sendo testado durante períodos de dois minutos. Essa metodologia permitiu avaliar o desempenho do sistema sob condições de carga controlada.

É importante reconhecer as limitações inerentes à metodologia empregada neste estudo. A amostra do levantamento, composta por vinte e um profissionais, embora tenha permitido a identificação de tendências relevantes, não foi dimensionada para possibilitar generalizações estatísticas amplas para a população de profissionais de tecnologia. Adicionalmente, o protótipo funcional, apesar de representar um cenário realista de e-commerce, foi executado em um ambiente controlado e com uma carga de usuários limitada. Essa configuração não contemplou a complexidade e as variáveis operacionais presentes em sistemas de produção de grande escala, o que restringe a aplicabilidade direta dos resultados a esses contextos.

3. Resultados e Discussão

Os dados coletados por meio do questionário eletrônico, aplicado a vinte e um profissionais de tecnologia, conforme detalhado por Silva (2025), revelaram padrões consistentes e insights valiosos sobre as práticas de arquitetura de software e comunicação entre serviços no ambiente corporativo brasileiro. Estes resultados, complementados pelas métricas de desempenho obtidas a partir do protótipo funcional, oferecem uma análise abrangente que valida e aprofunda as discussões teóricas existentes sobre arquiteturas monolíticas e de microsserviços. A pesquisa buscou não apenas identificar tendências, mas também compreender as razões subjacentes às decisões arquiteturais e suas implicações práticas, fornecendo um panorama robusto para profissionais e acadêmicos da área.

A análise da distribuição dos participantes por cargo atual, conforme apresentado na Figura 1, revelou uma predominância de desenvolvedores de software (42,9%), seguidos por engenheiros de software (19%) e gestores de tecnologia (9,5%). Esta composição da amostra é particularmente relevante, pois indica que a maioria dos respondentes possui um envolvimento direto e prático com o ciclo de vida do desenvolvimento de software, desde a concepção arquitetural até a implementação e manutenção diária dos sistemas. A experiência desses profissionais no “chão de fábrica” da tecnologia confere maior representatividade e credibilidade às percepções coletadas, uma vez que suas opiniões são forjadas na realidade dos desafios e sucessos enfrentados em projetos reais.

Figura 1. Distribuição dos participantes por cargo atual

Fonte: Dados da pesquisa (Silva, 2025)

A relevância da experiência prática é um ponto frequentemente destacado na literatura. Newman (2021) e Richardson (2018) enfatizam que a coleta de percepções de profissionais com experiência é fundamental para complementar análises experimentais em arquitetura de software, pois as decisões arquiteturais não são puramente técnicas, mas também influenciadas por fatores organizacionais, culturais e de negócio. A presença de gestores de tecnologia na amostra também é crucial, pois eles frequentemente atuam como ponte entre as necessidades de negócio e as soluções técnicas, influenciando diretamente as escolhas arquiteturais e a alocação de recursos. Assim, a diversidade de cargos na amostra contribui para uma visão multifacetada e pragmática dos desafios e oportunidades inerentes à escolha e implementação de arquiteturas de software.

A experiência profissional dos participantes, conforme ilustrado na Figura 2, demonstra uma maturidade técnica significativa da amostra. Mais de 66% dos respondentes possuem experiência superior a seis anos na área de tecnologia, com 42,9% ultrapassando dez anos de atuação. Esse perfil de alta experiência é um diferencial, pois as opiniões coletadas não se baseiam apenas em conhecimento teórico, mas refletem vivências concretas com os desafios de escalar sistemas, manter aplicações em produção e adaptar arquiteturas a requisitos de negócio em constante mudança.

Figura 2. Distribuição dos participantes por tempo de experiência

Fonte: Dados da pesquisa (Silva, 2025)

A complexidade da engenharia de software, especialmente em sistemas distribuídos, exige um profundo conhecimento prático para tomar decisões arquiteturais informadas. Sommerville (2007) ressalta que a evolução dos sistemas de software para ambientes distribuídos com múltiplas dependências tecnológicas aumenta a complexidade e a necessidade de profissionais experientes. A capacidade de lidar com a evolução de sistemas legados, a integração de novas tecnologias e a otimização de desempenho em larga escala são habilidades que se desenvolvem com anos de prática. Portanto, a alta experiência da amostra fortalece a validade interna dos resultados da pesquisa, garantindo que as tendências e percepções identificadas são representativas de um entendimento aprofundado do domínio.

Em relação à arquitetura predominante nas organizações, os resultados indicaram que 47,6% das empresas utilizam arquiteturas híbridas, onde monólitos e microsserviços coexistem, enquanto 42,9% operam exclusivamente com microsserviços, e apenas 4,8% mantêm uma arquitetura puramente monolítica. Este achado corrobora a observação de Newman (2019), que descreve a migração de monólitos para microsserviços como um processo gradual e evolutivo, onde as organizações frequentemente mantêm ambos os modelos durante períodos de transição. A adoção de uma abordagem híbrida reflete um pragmatismo de mercado, onde as empresas buscam equilibrar a estabilidade de sistemas legados com a agilidade e escalabilidade oferecidas pelos microsserviços.

A coexistência de diferentes estilos arquiteturais dentro de uma mesma organização não é apenas uma fase de transição, mas muitas vezes uma estratégia deliberada para otimizar recursos e atender a diferentes requisitos de negócio. Fowler e Lewis (2014) argumentam que a escolha arquitetural deve ser guiada pelas necessidades específicas do domínio e da organização, e não por uma adesão cega a tendências. Em um ambiente híbrido, sistemas monolíticos podem ser mantidos para domínios de negócio estáveis e menos voláteis, onde a simplicidade de desenvolvimento e manutenção inicial é uma vantagem. Por outro lado, microsserviços são adotados para novas funcionalidades ou domínios que exigem alta escalabilidade, resiliência e a capacidade de equipes independentes entregarem valor rapidamente. Essa flexibilidade permite que as organizações capitalizem os benefícios de ambos os modelos, mitigando os riscos associados a uma migração completa e abrupta.

Os métodos de comunicação entre serviços adotados pelas organizações, conforme ilustrado na Figura 3, revelam que 76,2% dos profissionais indicam que a escolha depende do tipo de operação. A comunicação assíncrona é predominante para 19% dos respondentes, enquanto a síncrona é a escolha principal para apenas 4,8%. Este resultado sublinha a importância de uma abordagem contextualizada na definição dos padrões de comunicação, reforçando a ideia de que não existe uma solução universalmente superior, mas sim a mais adequada para cada cenário específico.

Figura 3. Métodos de comunicação entre serviços adotados pelas organizações

Fonte: Dados da pesquisa (Silva, 2025)

A percepção de que a escolha do método de comunicação é dependente do contexto está em linha com a literatura especializada. Richardson (2018) detalha que a comunicação síncrona, tipicamente via REST/HTTP, é mais simples de implementar e depurar, sendo ideal para operações que exigem uma resposta imediata e forte consistência. No entanto, ela introduz acoplamento temporal entre os serviços, tornando o sistema mais suscetível a falhas em cascata e limitando a escalabilidade. Em contraste, a comunicação assíncrona, frequentemente implementada com filas de mensagens, como o RabbitMQ, oferece maior resiliência, escalabilidade e desacoplamento, mas introduz complexidade na gestão de transações distribuídas e na garantia de consistência eventual (Namiot; Sneps-Sneppe, 2014). A preferência pela abordagem contextualizada demonstra que os profissionais estão cientes dessas trade-offs e buscam alinhar a tecnologia com os requisitos funcionais e não funcionais de cada operação.

As principais razões citadas para a manutenção de sistemas monolíticos, apresentadas na Figura 4, incluem a simplicidade de código e estrutura (42,9%), facilidade de manutenção e implantação (38,1%), e herança de sistemas antigos/legados (38,1%). Esses fatores destacam que, apesar da popularidade dos microsserviços, os monólitos ainda possuem um lugar válido no ecossistema de software, especialmente em contextos onde a complexidade do domínio é baixa ou onde a equipe é menor.

Figura 4. Razões para manutenção de arquitetura monolítica

Fonte: Dados da pesquisa (Silva, 2025)

Newman (2021) argumenta que monólitos bem estruturados continuam sendo uma escolha eficaz para equipes menores ou domínios de baixa complexidade, onde a sobrecarga operacional e a complexidade adicional dos microsserviços não se justificam. A simplicidade de um monólito pode acelerar o desenvolvimento inicial e reduzir os custos de manutenção em cenários específicos. A presença significativa de “herança de sistemas antigos (legado)” como uma razão para a manutenção de monólitos aponta para um desafio comum no setor: a migração de sistemas legados para arquiteturas distribuídas é um processo complexo, caro e arriscado. Muitas organizações optam por manter seus monólitos legados, aplicando estratégias de modernização gradual ou encapsulamento, em vez de uma reescrita completa, pois o custo e o risco da migração podem superar os benefícios percebidos no curto e médio prazo (Bass et al., 2021). Isso ressalta a importância de uma análise de custo-benefício cuidadosa antes de embarcar em grandes transformações arquiteturais.

O protótipo desenvolvido permitiu uma comparação empírica entre os modos de comunicação síncrono e assíncrono em um ambiente controlado, utilizando testes de carga com 50 usuários concorrentes. As métricas de desempenho, coletadas via Prometheus e visualizadas no Grafana, forneceram insights quantitativos sobre latência, throughput e taxa de erros. A Tabela 2 apresenta um comparativo detalhado da latência para a operação de checkout, um fluxo que envolve múltiplos serviços e, portanto, representa um cenário de complexidade transacional relevante.

Tabela 2. Comparativo de latência para operação de checkout

Métrica	Síncrono	Assíncrono
Latência P50	450 ms	85 ms
Latência P95	1.200 ms	180 ms
Latência P99	2.500 ms	350 ms
Taxa de erro	2,1%	0,8%

Fonte: Métricas coletadas via Prometheus (2026)

Os dados da Tabela 2 evidenciam uma diferença significativa na latência entre os dois modos de comunicação. A latência mediana (P50) no modo assíncrono foi de 85 ms, aproximadamente cinco vezes menor que os 450 ms registrados no modo síncrono. Da mesma forma, as latências nos percentis P95 e P99 foram substancialmente menores no modo assíncrono (180 ms e 350 ms, respectivamente) em comparação com o modo síncrono (1.200 ms e 2.500 ms). Essa disparidade é crucial, pois a latência percebida pelo usuário é um fator determinante na experiência de uso e na satisfação do cliente. No modo síncrono, o cliente permanece bloqueado aguardando a conclusão de todas as etapas da transação, o que significa que qualquer lentidão em um dos serviços impacta diretamente o tempo total de resposta. Em contraste, no modo assíncrono, o cliente recebe uma resposta imediata após a publicação do evento inicial, com o processamento subsequente ocorrendo em segundo plano. Richardson (2018) denomina essa abordagem como “resposta otimista”, onde o sistema assume que a operação será concluída com sucesso e notifica o cliente posteriormente em caso de falha. Essa estratégia é particularmente vantajosa para operações que podem tolerar consistência eventual, conforme discutido por Kleppmann (2017), permitindo uma melhor experiência do usuário em sistemas de alto volume.

Além da latência, a taxa de erros também apresentou uma melhoria notável no modo assíncrono, com 0,8% de erros em comparação com 2,1% no modo síncrono. Essa redução pode ser atribuída ao mecanismo de retry com backoff exponencial implementado nas filas do RabbitMQ, que confere maior resiliência ao sistema distribuído. Em um sistema síncrono, uma falha em qualquer serviço intermediário pode levar a uma falha imediata da transação completa, exigindo que o cliente ou o serviço chamador lide com a retentativa. No modelo assíncrono, a persistência das mensagens em filas e a capacidade de reprocessamento em caso de falha de um worker contribuem para um sistema mais robusto e tolerante a falhas, um aspecto fundamental para a operação de sistemas distribuídos em larga escala (Sridharan, 2018).

A Tabela 3 apresenta as métricas de throughput para os modos de comunicação, demonstrando a capacidade de processamento de cada abordagem.

Tabela 3. Comparativo de throughput por modo de comunicação

Métrica	Síncrono	Assíncrono
Requisições por segundo (checkout)	12,5 req/s	45,2 req/s
Requisições por segundo (catálogo)	156,3 req/s	158,7 req/s
Tempo médio de resposta (checkout)	480 ms	92 ms

Fonte: Métricas coletadas via Prometheus (2026)

O throughput superior do modo assíncrono nas operações de checkout (45,2 requisições por segundo) em comparação com o modo síncrono (12,5 requisições por segundo) é um achado significativo. Essa diferença de quase quatro vezes na capacidade de processamento para operações complexas é explicada pela liberação mais rápida dos recursos do servidor no modo assíncrono. Enquanto no modo síncrono o servidor aguarda a conclusão de todas as chamadas de serviço dependentes, no modo assíncrono, a requisição retorna ao cliente imediatamente após a publicação do evento inicial, permitindo que o servidor processe novas requisições. O processamento ocorre em paralelo via workers que consomem as filas de mensagens, otimizando o uso dos recursos e aumentando a capacidade de lidar com um volume maior de requisições simultâneas.

Para operações de leitura mais simples, como a navegação de catálogo, a diferença de throughput entre os modos síncrono e assíncrono foi marginal (156,3 req/s vs 158,7 req/s). Isso sugere que, para operações que não envolvem comunicação entre múltiplos serviços ou transações complexas, os benefícios da comunicação assíncrona são menos pronunciados. Este resultado reforça a percepção dos profissionais de que a escolha do padrão de comunicação deve ser contextual, dependendo da natureza da operação. A Figura 5 ilustra visualmente essa superioridade do throughput assíncrono em operações transacionais complexas, mostrando uma capacidade de processamento mais elevada e estável ao longo do tempo de teste.

Figura 5. Comparativo de throughput entre comunicação síncrona e assíncrona

Fonte: Dashboard Grafana – E-commerce Sync vs Async Comparison (2026)

A análise do gráfico de throughput na Figura 5 corrobora os dados da Tabela 3, evidenciando que o modo assíncrono mantém um throughput consistentemente mais alto e com menor variação ao longo do tempo de teste, especialmente em picos de carga. Essa estabilidade é um atributo crítico para sistemas que precisam garantir desempenho previsível sob condições variáveis de demanda. A capacidade de um sistema de manter um alto throughput sem degradação significativa sob carga é um indicador chave de sua escalabilidade e resiliência, conforme destacado por Sommerville (2007) e Bass et al. (2021). A comunicação assíncrona, ao desacoplar os serviços e permitir o processamento em segundo plano, distribui a carga de trabalho de forma mais eficiente, evitando gargalos que são comuns em arquiteturas síncronas sob estresse.

É fundamental ressaltar que a menor latência percebida pelo usuário no modo assíncrono não implica necessariamente que o tempo total de processamento da transação seja mais rápido. O tempo completo de execução da Saga, que engloba todas as etapas da transação distribuída, pode ser equivalente ou até superior ao do modo síncrono. A diferença reside na experiência do usuário: enquanto no modo síncrono o usuário aguarda a conclusão completa da operação, no assíncrono ele recebe uma confirmação de aceite rapidamente e pode continuar interagindo com o sistema. Essa abordagem é ideal para operações que podem tolerar consistência eventual, onde a consistência dos dados é alcançada ao longo do tempo, e não imediatamente após a requisição inicial (Kleppmann, 2017). A escolha entre consistência forte e consistência eventual é uma decisão arquitetural estratégica que deve ser alinhada com os requisitos de negócio e a tolerância a falhas do sistema.

A predominância do RabbitMQ, citado por 52,4% dos participantes da pesquisa como ferramenta de mensageria, e sua adoção no protótipo, demonstra a relevância dessa tecnologia para cenários de e-commerce e sistemas distribuídos. O RabbitMQ oferece suporte nativo a Dead Letter Queues (DLQ), que são essenciais para o tratamento de mensagens que não puderam ser processadas com sucesso, facilitando o reprocessamento e a recuperação de falhas. Além disso, sua interface de gerenciamento visual auxilia na operação e no diagnóstico do sistema, tornando-o uma escolha robusta para orquestração de eventos e transações distribuídas. Newman (2021) enfatiza que a escolha de uma ferramenta de mensageria deve considerar não apenas requisitos técnicos, mas também a familiaridade da equipe com a tecnologia e a maturidade da documentação disponível, fatores que o RabbitMQ geralmente atende.

A adoção universal de ferramentas de observabilidade, mencionada por 100% dos respondentes da pesquisa, reflete a complexidade inerente a sistemas distribuídos modernos e a necessidade crítica de visibilidade sobre o comportamento das aplicações em produção. Em consonância com essa prática de mercado, o protótipo implementou os três pilares da observabilidade, conforme descrito por Sridharan (2018): métricas, logs e traces. O Prometheus foi utilizado para coletar métricas quantitativas de desempenho, como throughput e latência, que foram visualizadas em dashboards do Grafana. Os logs estruturados por serviço facilitaram a correlação de eventos e a depuração. Por fim, o Jaeger, integrado ao OpenTelemetry, possibilitou o rastreamento distribuído completo de uma requisição ao longo dos diferentes microsserviços, permitindo identificar gargalos e pontos de falha em um ambiente complexo. A observabilidade robusta é, portanto, um componente indispensável para a operação e manutenção eficaz de qualquer sistema distribuído, garantindo que as equipes possam diagnosticar problemas rapidamente e manter a saúde do sistema em produção.

4. Conclusão

Conclui-se que o objetivo foi atingido, ao analisar comparativamente as abordagens arquiteturais monolítica e baseada em microsserviços, identificando os fatores que orientam a adoção de cada modelo e compreendendo seus impactos na escalabilidade, manutenibilidade e eficiência operacional no longo prazo. A pesquisa revelou uma predominância de arquiteturas híbridas no mercado, evidenciando uma abordagem pragmática onde monólitos e microsserviços coexistem para equilibrar estabilidade e agilidade. Os resultados empíricos do protótipo confirmaram que a escolha do padrão de comunicação entre serviços é contextual: a comunicação assíncrona, com RabbitMQ e padrão Saga, demonstrou menor latência percebida pelo usuário e maior throughput em operações transacionais complexas, enquanto a síncrona, via REST/HTTP, é mais adequada para cenários que exigem confirmação imediata e simplicidade. A observabilidade robusta, com métricas, logs e traces, mostrou-se indispensável para a operação eficaz de sistemas distribuídos, sendo universalmente adotada pelos profissionais.

Apesar das contribuições, este estudo apresenta limitações inerentes à sua metodologia. A amostra de 21 profissionais, embora qualificada, não permite generalizações estatísticas amplas. Adicionalmente, o protótipo funcional, representativo de um cenário de e-commerce, foi executado em ambiente controlado e com carga limitada, o que pode não refletir integralmente a complexidade e as variáveis de sistemas em produção de grande escala. Como sugestão para trabalhos futuros, recomenda-se a expansão da pesquisa para uma amostra maior de profissionais e a implementação de padrões de resiliência adicionais, como Circuit Breaker e retry com backoff exponencial. A realização de testes de desempenho em ambientes de produção, com maior escala e diversidade de cenários, poderia aprofundar a compreensão dos impactos arquiteturais em condições reais de operação.

Referências Bibliográficas

Bass, L.; Clements, P.; Kazman, R. 2021. Software Architecture in Practice. 4ed. Addison-Wesley Professional, Boston, MA, EUA.

Fowler, M.; Lewis, J. 2014. Microservices: a definition of this new architectural term. Disponível em: <https://martinfowler.com/articles/microservices.html>. Acesso em: 05 out. 2025.

Grafana – E-commerce Sync vs Async Comparison, 2026 [Referência completa não encontrada no documento original]

Grafana, 2026 [Referência completa não encontrada no documento original]

Jaeger, 2026 [Referência completa não encontrada no documento original]

Kleppmann, M. 2017. Designing Data-Intensive Applications: the big ideas behind reliable, scalable, and maintainable systems. 1ed. O’Reilly Media, Sebastopol, CA, EUA.

Namiot, D.; Sneps-Sneppe, M. 2014. On micro-services architecture. International Journal of Open Information Technologies 2(9): 24-27.

Newman, S. 2019. Monolith to Microservices: evolutionary patterns to transform your monolith. 1ed. O’Reilly Media, Sebastopol, CA, EUA. Disponível em: <https://www.oreilly.com/library/view/monolith-to-microservices/9781492047834/>. Acesso em: 26 set. 2025.

Newman, S. 2021. Building Microservices: designing fine-grained systems. 2ed. O’Reilly Media, Sebastopol, CA, EUA. Disponível em: <https://www.oreilly.com/library/view/building-microservices-2nd/9781492034018/>. Acesso em: 03 out. 2025.

Prometheus, 2026 [Referência completa não encontrada no documento original]

Richardson, C. 2018. Microservices Patterns: with examples in Java. 1ed. Manning Publications, Shelter Island, NY, EUA.

Silva, V.C.R. 2025. Pesquisa sobre Práticas de Comunicação entre Serviços: monólitos e microsserviços. Instrumento de coleta de Dados do Trabalho de Conclusão de Curso em MBA em Engenharia de Software. Universidade de São Paulo, São Paulo, SP, Brasil.

Sommerville, I. 2007. Engenharia de Software. 8ed. Pearson Addison Wesley, São Paulo, SP, Brasil.

Sridharan, C. 2018. Distributed Systems Observability: a guide to building robust systems. 1ed. O’Reilly Media, Sebastopol, CA, EUA.

Artigo 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