Gabriel Portela Gomes; Luciano Bérgamo

DOI: 10.22167/2675-6528-202600841

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

Resumo

A crescente adoção de arquiteturas distribuídas ampliou o uso de microsserviços no desenvolvimento de aplicações modernas, introduzindo desafios na comunicação entre serviços e na consistência dos dados. Analisou-se o impacto dos modelos de comunicação síncrona e assíncrona no desempenho, acoplamento temporal, tolerância a falhas e consistência de sistemas baseados em microsserviços. Para isso, adotou-se uma abordagem experimental, implementando dois modelos de comunicação em um sistema que simulou um comércio eletrônico. Realizaram-se testes de carga e cenários de falha controlados, com testes automatizados e consultas a banco de dados para validar a consistência dos registros, coletando métricas como tempo de resposta, vazão, taxa de erro e integridade dos dados. Os resultados mostraram que o modelo síncrono apresentou degradação significativa no tempo de resposta sob alta carga e em cenários de falha. Em contraste, o modelo assíncrono demonstrou maior estabilidade, melhor escalabilidade e maior capacidade de absorção de falhas, utilizando mecanismos como retentativas e “Dead Letter Queue”. Ambos os modelos mantiveram a consistência final dos dados em cenários de falhas de negócio, desde que as regras de negócio fossem corretamente implementadas. Concluiu-se que o modelo assíncrono é mais adequado para ambientes distribuídos que demandam alta disponibilidade e resiliência, embora sua adoção exija considerar os “trade-offs” relacionados à complexidade e à necessidade de respostas em tempo real.

Palavras-chave: Disponibilidade; Escalabilidade; Modelo assíncrono; Modelo síncrono; Resiliência.

1. Introdução

A transformação digital impulsionou uma reestruturação significativa no desenvolvimento de software, demandando arquiteturas que suportem entregas ágeis e contínuas, alta escalabilidade, resiliência e facilidade de manutenção. Esse cenário dinâmico é marcado pela constante evolução dos estilos arquiteturais, com a adoção de abordagens mais adequadas às novas restrições tecnológicas e demandas de mercado (Ford et al., 2024).

Nesse contexto, a arquitetura de microsserviços emergiu como um paradigma amplamente adotado. Conforme Wolff (2016), essa abordagem estrutura aplicações em serviços pequenos, independentes e fracamente acoplados, que podem ser desenvolvidos, implantados e escalados de forma autônoma. Tal flexibilidade e capacidade de evolução contínua são cruciais para sistemas modernos.

No entanto, a adoção de microsserviços introduz desafios inerentes aos sistemas distribuídos. Segundo Kleppmann (2017), esses sistemas são suscetíveis a falhas parciais, onde componentes podem falhar independentemente. Isso exige a implementação de mecanismos robustos de tolerância a falhas e padrões de resiliência, como repetição de requisições e filas de mensagens, visando mitigar os efeitos de falhas temporárias no sistema como um todo.

Além das questões de resiliência, a comunicação entre os microsserviços é um ponto crítico que adiciona complexidade ao desenvolvimento de software. A escolha do modelo de comunicação impacta diretamente o desempenho das chamadas, a compatibilidade de interfaces, o tratamento de erros e as tecnologias empregadas (Newman, 2022).

A comunicação entre microsserviços pode ser implementada de forma síncrona ou assíncrona. No modelo síncrono, o serviço solicitante aguarda a resposta do receptor, o que pode levar a um acoplamento temporal. Em contraste, a comunicação assíncrona é baseada em eventos e mensagens, permitindo que o serviço solicitante prossiga com seu processamento sem aguardar uma resposta imediata. Esse modelo favorece o desacoplamento temporal e aumenta a resiliência em ambientes distribuídos (Richards & Ford, 2024; Newman, 2022).

A problemática central reside na complexidade da comunicação em arquiteturas de microsserviços, que afeta diretamente o desempenho do sistema e o grau de acoplamento temporal entre os serviços. Uma escolha inadequada do modelo de comunicação pode comprometer a disponibilidade, a escalabilidade e a tolerância a falhas, tornando essencial uma análise comparativa baseada em evidências práticas.

Diante dessa complexidade na definição da comunicação em arquiteturas de microsserviços, justifica-se a realização de uma pesquisa aplicada voltada à quantificação do impacto dos paradigmas de comunicação síncrona e assíncrona. Para isso, foi desenvolvido um protótipo de back-end de um sistema de comércio eletrônico, a partir do qual foram mensurados e comparados o desempenho e a resiliência do sistema, evidenciando os trade-offs entre os modelos de comunicação.

Nesse contexto, este estudo tem como objetivo avaliar o impacto dos modelos de comunicação síncrona e assíncrona em arquiteturas de microsserviços, por meio da análise comparativa de métricas de desempenho e resiliência obtidas a partir da implementação e dos testes realizados com o protótipo desenvolvido.

2. Material e Métodos

A pesquisa foi aplicada, quantitativa e experimental, investigando desempenho, resiliência e acoplamento temporal em sistemas distribuídos (Wazlawick, 2009). O paradigma de comunicação entre microsserviços atuou como variável independente (Gil, 2008). Não houve participação humana ou coleta de dados sensíveis, baseando-se em testes técnicos controlados, sem risco ético ou necessidade de submissão a comitês de ética.

Desenvolveu-se um protótipo de back-end de comércio eletrônico em arquitetura de microsserviços, composto por três serviços autônomos: “Order Service”, “Inventory Service” e “Payment Service”. A decomposição seguiu o padrão “Database-per-service” (Richardson, 2019), com bancos de dados independentes. Códigos-fonte foram disponibilizados.

O protótipo foi implementado em Java 21, com o framework Quarkus (Red Hat, 2023; Quarkus, 2026). A comunicação síncrona utilizou HTTP (Newman, 2022), e a assíncrona, Apache Kafka (Kleppmann, 2017). PostgreSQL foi empregado para dados, e Docker para conteinerização, garantindo ambientes isolados e reprodutibilidade.

A arquitetura interna dos microsserviços seguiu princípios de separação de responsabilidades (Martin, 2009). No modelo síncrono, a comunicação HTTP via REST foi orquestrada pelo “Order Service”, realizando chamadas encadeadas para “Inventory Service” e “Payment Service”. Cada etapa do pedido aguardou a conclusão da anterior, gerando acoplamento temporal (Newman, 2022).

O modelo assíncrono utilizou comunicação baseada em eventos via broker de mensagens, aproximando-se da coreografia. O “Order Service” publicou eventos em tópicos, consumidos independentemente pelos demais serviços. Isso permitiu troca indireta de informações, reduzindo acoplamento temporal e aumentando resiliência (Newman, 2022). O processamento do pedido ocorreu reativamente.

A análise de falhas manteve a persistência dos pedidos (Kleppmann, 2017), distinguindo falhas negociais de técnicas. Ambos os modelos empregaram reprocessamento automático para falhas transitórias. No síncrono, ações de compensação desfaziam reservas em falhas de pagamento. No assíncrono, além das retentativas, utilizou-se “Dead Letter Queue” (DLQ) para mensagens não processadas e eventos de compensação para falhas negociais, assegurando consistência eventual.

Os testes de desempenho foram realizados com Apache JMeter, configurado para gerar requisições HTTP ao “Order Service”, simulando criação de pedidos. A ferramenta operou isoladamente. Aplicaram-se níveis crescentes de concorrência e cenários de falhas controladas (indisponibilidade de serviços, erros simulados) para avaliar desempenho e resiliência. Parâmetros como “Threads”, “Ramp-up” e “Loop Count” foram definidos e disponibilizados.

Quatro cenários de teste foram executados. Carga Nominal avaliou latência e vazão sob diferentes cargas. Erro Negocial analisou falhas de negócio, configurando recusas de pagamento para verificar mecanismos de compensação. Falha Total do “Payment Service” simulou indisponibilidade completa do serviço por trinta segundos. Falha Parcial do “Payment Service” investigou falhas parciais, desativando seu banco de dados por trinta segundos. Ambos os cenários de falha permitiram analisar a reação da aplicação, impactos em latência e taxa de erro, e a atuação de retentativas e DLQ.

As métricas capturadas para avaliação quantitativa incluíram Tempo de Resposta (latência), Vazão (throughput – requisições processadas com sucesso por unidade de tempo) e Taxa de Erro (percentual de requisições com falhas). A consistência dos dados foi verificada por consultas SQL diretas ao banco de dados do “Order Service” via DBeaver. Os dados foram filtrados por modelo de comunicação e período de execução. Relatórios do JMeter e resultados das consultas foram organizados em planilhas eletrônicas para análise comparativa.

3. Resultados e Discussão

Os experimentos foram conduzidos em um ambiente controlado, com o objetivo de avaliar o comportamento de sistemas baseados em microsserviços sob diferentes níveis de concorrência e em cenários de falha, comparando os modelos de comunicação síncrona e assíncrona. A coleta de dados focou em métricas de desempenho, como tempo de resposta, vazão e taxa de erro, além da verificação da consistência dos dados. Os resultados permitiram uma análise quantitativa e qualitativa dos impactos de cada modelo, revelando suas características e limitações em contextos específicos de carga e resiliência, conforme detalhado nos cenários experimentais.

Inicialmente, no Cenário 1, que avaliou a carga nominal, observou-se que o tempo de resposta médio no modelo síncrono apresentou um crescimento não linear à medida que o número de usuários simultâneos aumentou. Em cargas baixas, o tempo de resposta era reduzido, mas em cenários de alta concorrência, como com 300 usuários, o tempo médio de resposta atingiu 526,52 milissegundos, um aumento significativo em comparação aos 15,27 milissegundos registrados com 50 usuários. Esse comportamento é atribuído ao caráter bloqueante da comunicação HTTP, onde as requisições aguardam a conclusão de chamadas subsequentes, ocupando recursos do servidor e formando filas de espera internas, o que amplifica o tempo total de processamento.

Em contraste, o modelo assíncrono demonstrou uma notável estabilidade no tempo de resposta médio, mesmo sob o aumento da carga. Com 50 usuários, o tempo médio foi de 4,01 milissegundos, e com 300 usuários, esse valor subiu apenas para 7,68 milissegundos. Essa estabilidade decorre do fato de que o serviço de pedidos, no modelo assíncrono, não precisa aguardar o processamento completo das etapas subsequentes, apenas registrando a requisição e publicando um evento inicial no “broker” de mensagens. Desse modo, o tempo de resposta ao cliente reflete primariamente o custo de aceitação da requisição, e não o tempo total da operação distribuída.

A análise da vazão, ou Transações por Segundo (TPS), no Cenário 1, também revelou diferenças importantes. No modelo síncrono, o crescimento da vazão mostrou uma tendência de limitação à medida que a quantidade de solicitações simultâneas aumentava. Embora tenha atingido 240,97 TPS com 300 usuários, a taxa de crescimento foi menos consistente em comparação com o modelo assíncrono. Isso ocorre porque cada requisição síncrona permanece ativa durante toda a cadeia de chamadas, restringindo a capacidade total de processamento pelo número de “threads” disponíveis e pelo tempo de resposta dos serviços dependentes, indicando uma saturação progressiva dos recursos do servidor.

Por outro lado, o modelo assíncrono exibiu um crescimento mais consistente da vazão em relação ao aumento do número de usuários, alcançando 392,60 TPS com 300 usuários. Esse desempenho superior evidencia uma melhor utilização dos recursos, pois o serviço de entrada não permanece bloqueado durante todo o processamento das etapas internas. Essa característica confere ao modelo assíncrono uma maior capacidade de escalabilidade horizontal, beneficiando-se do desacoplamento entre os serviços e distribuindo as cargas de processamento ao longo do tempo, o que é crucial para absorver picos de carga sem impactar significativamente a experiência do usuário.

A ausência de erros em ambos os modelos no Cenário 1, com taxa de erro de 0%, indica que o sistema operou dentro de seus limites funcionais. As diferenças observadas no desempenho podem ser predominantemente atribuídas ao modelo de comunicação. Essa análise conjunta das métricas de tempo de resposta e vazão demonstra um “trade-off” fundamental: enquanto o modelo síncrono oferece simplicidade de implementação e resposta imediata, ele apresenta limitações de escalabilidade sob alta carga. O modelo assíncrono, por sua vez, prioriza a disponibilidade e a capacidade de processamento consistente, embora exija maior complexidade arquitetural e a adoção de consistência eventual.

No Cenário 2, que simulou falhas de natureza negocial, a taxa de erro negocial manteve-se próxima ao valor esperado de aproximadamente 40% em todos os experimentos, tanto no modelo síncrono quanto no assíncrono. Por exemplo, com 200 usuários, o modelo síncrono registrou 39,48% de erro, enquanto o assíncrono registrou 40,22%. Isso confirmou a eficácia da configuração da ferramenta JMeter para induzir falhas negociais e a consistência dos testes. Em termos de desempenho, o modelo síncrono novamente apresentou um aumento significativo no tempo médio de resposta com o crescimento da carga, atingindo 116,90 milissegundos com 200 usuários, em contraste com os 4,83 milissegundos do modelo assíncrono para 50 usuários e 6,43 milissegundos para 200 usuários, que manteve tempos de resposta mais baixos e estáveis.

A consistência dos dados foi um ponto crucial de avaliação neste cenário. Não foram identificadas inconsistências no estado final dos pedidos em nenhum dos cenários analisados, independentemente do modelo de comunicação. Todas as requisições que resultaram em falha de pagamento apresentaram estados finais coerentes com as regras de negócio definidas, e as transações bem-sucedidas tiveram seus pedidos corretamente confirmados. Esse resultado evidenciou que, no modelo síncrono, a consistência é garantida de forma imediata devido ao encadeamento direto entre as operações. Já no modelo assíncrono, a ausência de inconsistências indica a eficácia dos mecanismos de compensação e atualização de estado implementados, mesmo diante do processamento desacoplado das etapas do fluxo, operando sob o princípio de consistência eventual (KLEPPMANN, 2017).

Os resultados do Cenário 2 indicam que a escolha entre os modelos de comunicação não impacta diretamente a consistência final dos dados em falhas negociais, mas influencia significativamente o desempenho e a complexidade da implementação. O modelo assíncrono oferece vantagens em desempenho e escalabilidade, mantendo tempos de resposta baixos e maior vazão mesmo sob carga elevada. Contudo, demanda maior complexidade na gestão do estado das operações, uma vez que o processamento ocorre de forma eventual. Essa observação reforça a necessidade de uma análise criteriosa dos “trade-offs” envolvidos na escolha do modelo de comunicação para cada aplicação.

No Cenário 3, que simulou a indisponibilidade total do “Payment Service”, as diferenças entre os modelos foram ainda mais evidentes. O modelo síncrono apresentou um pico de erros durante o período de falha, com a taxa de erro atingindo 100% e o tempo médio de resposta elevando-se abruptamente para 5001,02 milissegundos. A vazão caiu drasticamente para 10,74 TPS. Esse comportamento indica que as requisições não puderam ser concluídas devido à dependência imediata entre os serviços, demonstrando a falta de mecanismos de tolerância a falhas prolongadas, onde a indisponibilidade de um componente leva à falha total da operação.

Em contraste, o modelo assíncrono não demonstrou impacto significativo na taxa de erro, que permaneceu em 0% durante todo o experimento, mesmo diante da falha técnica simulada. O tempo médio de resposta manteve-se estável, com 4,18 milissegundos durante a falha, e a vazão permaneceu consistente em 164,81 TPS. Esse comportamento indica que as solicitações continuaram sendo aceitas e registradas, mesmo sem o processamento imediato das etapas seguintes, fortalecendo o desacoplamento temporal facilitado pela comunicação assíncrona (NEWMAN, 2022). Isso permitiu que o sistema preservasse sua disponibilidade mesmo com falhas em serviços dependentes.

A avaliação combinada das métricas de desempenho e erro ao longo do tempo neste cenário revelou uma diferença essencial na gestão de falhas de infraestrutura. O modelo síncrono exibiu uma falha imediata e perceptível ao usuário final, com aumento do tempo de resposta e da taxa de erro. Já o modelo assíncrono transferiu o efeito da falha para as fases internas do processamento, priorizando a disponibilidade e a continuidade das operações, mesmo que isso significasse adiar o processamento completo das requisições. A capacidade de absorver a falha sem impacto direto na interface de entrada do sistema é uma vantagem crucial do modelo assíncrono em ambientes distribuídos.

No Cenário 4, que investigou falhas parciais de infraestrutura (indisponibilidade do banco de dados do “Payment Service”), o modelo síncrono apresentou um comportamento semelhante ao cenário de falha total. A taxa de erro se manteve em 100% das requisições durante a indisponibilidade parcial do serviço, com o tempo médio de resposta elevando-se para 5000,92 milissegundos e a vazão caindo para 11,00 TPS. Isso reforça a forte dependência e o acoplamento temporal entre os serviços, onde a falha de um componente crítico, mesmo que parcial, bloqueia a conclusão das operações e resulta em falha total para o usuário.

Para o modelo assíncrono no Cenário 4, a maioria das requisições foi processada com sucesso após o restabelecimento do banco de dados, evidenciando a eficácia dos mecanismos de retentativa implementados. Mesmo durante a indisponibilidade parcial, as mensagens não foram descartadas imediatamente, sendo reprocessadas assim que o serviço voltou a operar. O tempo médio de resposta manteve-se estável em 3,63 milissegundos durante a falha, e a vazão em 11,00 TPS, indicando que o sistema continuou aceitando requisições. A presença de um pedido em estado pendente no banco de dados do “Order Service” ilustrou uma inconsistência temporária, característica de arquiteturas assíncronas, mas sem perda de dados.

A verificação do tópico “Dead Letter Queue” (DLQ) no modelo assíncrono, durante a falha parcial, revelou a presença de uma mensagem que não pôde ser processada com sucesso após as tentativas de reprocessamento. Essa mensagem no tópico “inventory-reserved-dlq” confirmou que o tempo de indisponibilidade do banco de dados superou a capacidade de recuperação automática dos mecanismos de retentativa. A utilização da DLQ demonstrou a capacidade do sistema de tratar falhas persistentes de forma estruturada, evitando a perda de dados da transação e isolando a operação problemática para análise e um possível reprocessamento posterior, garantindo maior robustez e confiabilidade da aplicação.

Os resultados obtidos permitiram concluir que o modelo de comunicação tem um impacto direto no desempenho de sistemas baseados em microsserviços, especialmente em situações de alta demanda e falhas. O modelo síncrono demonstrou restrições significativas relacionadas ao bloqueio de solicitações e ao uso intensivo de recursos, com degradação progressiva no tempo de resposta à medida que a concorrência aumentou, evidenciando um forte acoplamento entre serviços. Em contrapartida, o modelo assíncrono exibiu maior escalabilidade e estabilidade, mantendo um desempenho consistente mesmo sob altas cargas, e destacou-se pela capacidade de lidar com falhas transitórias, preservar estados intermediários e empregar mecanismos de reprocessamento e DLQ para gerenciar falhas persistentes, reforçando sua adequação a ambientes distribuídos que demandam alta disponibilidade e resiliência, apesar da maior complexidade arquitetural e da aceitação da consistência eventual.

4. Conclusão

Este estudo teve como objetivo avaliar o impacto dos modelos de comunicação síncrona e assíncrona em arquiteturas de microsserviços, por meio da análise comparativa de métricas de desempenho e resiliência obtidas a partir da implementação e dos testes realizados com um protótipo. Verificou-se que o modelo síncrono apresentou degradação significativa no tempo de resposta e na vazão sob alta carga, além de demonstrar alta suscetibilidade a falhas de infraestrutura, com interrupção total das operações e elevação abrupta da taxa de erro. Em contraste, o modelo assíncrono exibiu maior estabilidade no tempo de resposta e um crescimento mais consistente da vazão, mantendo a disponibilidade do sistema mesmo diante de falhas em serviços dependentes. Observou-se que a consistência final dos dados foi preservada em ambos os modelos, desde que mecanismos de compensação e retentativas fossem adequadamente implementados, com o modelo assíncrono utilizando eficazmente a “Dead Letter Queue” para gerenciar falhas persistentes. A principal contribuição deste trabalho reside na demonstração empírica dos “trade-offs” inerentes a cada modelo, fornecendo subsídios práticos para a tomada de decisão arquitetural em sistemas distribuídos.

Apesar dos achados, o estudo possui limitações relacionadas à simplificação das regras de negócio no protótipo, o que pode influenciar a complexidade de implementação dos mecanismos de consistência em cenários reais mais elaborados. Adicionalmente, a adoção do modelo assíncrono, embora mais resiliente e escalável, demanda maior complexidade arquitetural e a aceitação da consistência eventual, o que exige uma análise criteriosa das necessidades de resposta em tempo real da aplicação. Sugere-se para estudos futuros a investigação de outros padrões de resiliência e comunicação em microsserviços, bem como a avaliação do impacto desses modelos em cenários com maior complexidade de regras de negócio e volumes de dados, a fim de aprofundar a compreensão sobre os “trade-offs” envolvidos na escolha da arquitetura de comunicação.

Referências Bibliográficas

FORD, N.; RICHARDS, M.; SADALAGE, P.; DEHGHANI, Z. Arquitetura de software: as partes difíceis – análises modernas de trade-off para arquiteturas distribuídas. Tradução: Leandro Menegaz. Rio de Janeiro: Alta Books, 2024.

GIL, A.C. Métodos e técnicas de pesquisa social. 6. ed. São Paulo: Atlas, 2008.

KLEPPMANN, M. Designing data-intensive applications: the big ideas behind reliable, scalable, and maintainable systems. Sebastopol: O’Reilly Media, 2017.

MARTIN, R.C. Código limpo: habilidades práticas do Agile software. Tradução de Edson Furmankiewicz. Rio de Janeiro: Alta Books, 2009.

NEWMAN, S. Criando microsserviços: projetando sistemas com componentes menores e mais especializados. 2. ed. São Paulo: Novatec Editora, 2022.

QUARKUS. Start coding with code.quarkus.io. [S.I.], [s.d.]. Disponível em: <https://code.quarkus.io>. Acesso em: 04 jan. 2026.

RED HAT. O que é o Quarkus? [S.I.], 2023. Disponível em: <https://www.redhat.com/pt-br/topics/cloud-native-apps/what-is-quarkus>. Acesso em: 15 jan. 2026.

RICHARDS, M.; FORD, N. Fundamentos da arquitetura de software: uma abordagem de engenharia. Tradução: Eveline Machado. Rio de Janeiro: Alta Books, 2024.

RICHARDSON, Chris. Microservices patterns: with examples in Java. Shelter Island: Manning Publications, 2019.

WAZLAWICK, R.S. Metodologia de pesquisa para ciência da computação. Rio de Janeiro: Elsevier, 2009.

WOLFF, Eberhard. Microservices: Flexible Software Architecture. Boston: Addison-Wesley, 2016.

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