Caio Henrique Domingues Leite; Emerson Aparecido Mouco Júnior

DOI: 10.22167/2675-6528-202600636

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

Resumo

A arquitetura de microsserviços deslocou parte da complexidade do software para a camada de comunicação entre serviços, tornando a escolha entre chamadas síncronas e assíncronas crucial para o desempenho do sistema. Este estudo comparou o comportamento de três estratégias de comunicação em .NET 8 – REST, gRPC e RabbitMQ – em um arranjo com Gateway HTTP intermediário. Para isso, realizou-se um experimento controlado em ambiente Docker, com cinco execuções independentes por cenário, utilizando Apache JMeter para gerar carga, payload padronizado de 2.048 caracteres e atraso sintético de 10 ms. REST e gRPC apresentaram desempenho próximo, com medianas de latência de 13 ms e 14 ms e uma diferença de throughput de apenas 1,7%. O RabbitMQ, operando em modo fire-and-forget, registrou um throughput de publicação de 1.614,6 req/s e mediana de 2,4 ms no gateway. Contudo, a latência fim a fim com consumidor único atingiu 651.649 ms, evidenciando que a resposta rápida no gateway não correspondia à conclusão do processamento. Em um cenário exploratório com três consumidores e prefetchCount=10, essa mediana de latência fim a fim reduziu 69%. Os resultados indicaram que a superioridade de uma tecnologia sobre outra não é uma propriedade intrínseca do mecanismo de comunicação, mas sim do arranjo arquitetural e operacional em que foi empregada.

Palavras-chave: Arquitetura de microsserviços; Desempenho; gRPC; RabbitMQ; REST.

1. Introdução

  A arquitetura de microsserviços transformou o desenvolvimento e a implantação de aplicações, promovendo maior flexibilidade e escalabilidade ao decompor sistemas monolíticos em componentes menores e independentes. Contudo, essa abordagem transfere uma parcela significativa da complexidade do software para a camada de comunicação entre os serviços. Essa mudança torna a escolha dos padrões de integração um fator crítico para o desempenho e a robustez do sistema, conforme apontado por Newman (2021), Richardson (2018) e Fowler e Lewis (2014). 

  Nesse contexto, a decisão entre chamadas síncronas e assíncronas deixa de ser uma questão secundária, passando a influenciar diretamente métricas essenciais como latência, vazão (throughput), acoplamento temporal, robustez operacional e o esforço de manutenção. Em padrões síncronos, como REST (Representational State Transfer) e gRPC (Google Remote Procedure Call), a interação ocorre no modelo de requisição-resposta. Nesses casos, a latência percebida pelo cliente geralmente inclui o tempo de espera pelo processamento completo no serviço chamado. 

  Por outro lado, em cenários assíncronos, tipicamente baseados em sistemas de mensageria como o RabbitMQ, a resposta ao cliente pode ser emitida no momento da publicação da mensagem, enquanto o processamento efetivo é concluído posteriormente por um consumidor. Essa distinção é fundamental, pois exige que a latência observada pelo cliente seja separada da latência fim a fim, que representa o tempo total até a conclusão do processamento completo. A presença de um API Gateway, um padrão comum em arquiteturas de microsserviços para centralizar o roteamento e a exposição de endpoints (Taibi et al., 2018), também pode introduzir uma camada adicional de latência que afeta o desempenho percebido pelo cliente (Newman, 2021). 

  Estudos prévios já indicaram diferenças entre essas abordagens, mas a comparação em recortes específicos ainda apresenta lacunas. Hong et al. (2018) observaram maior estabilidade do RabbitMQ em relação ao REST sob alta concorrência, embora sem uma distinção clara entre tempo de publicação e latência fim a fim. Fernandes et al. (2013) concluíram que o protocolo AMQP oferece maior throughput que REST para grandes volumes de mensagens, mas em um contexto experimental anterior ao padrão de microsserviços e com métricas e infraestrutura distintas. 

  Para o gRPC, a literatura ressalta que os resultados de benchmark são fortemente dependentes do desenho experimental, incluindo o controle de warm-up, o tamanho do payload e os parâmetros de execução (Çiftçi e Çiloğlugil, 2025). No ecossistema .NET, especificamente, ainda são menos frequentes os estudos que comparam REST e gRPC com a mesma lógica de negócio e o mesmo perfil de carga. Na prática, a escolha entre essas tecnologias é frequentemente influenciada pela stack tecnológica dominada pela equipe, pelas restrições do projeto e por expectativas de desempenho que nem sempre são validadas experimentalmente (Newman, 2021; Richardson, 2018). O comportamento dessas tecnologias varia conforme o contexto e o ambiente, desaconselhando generalizações (Dragoni et al., 2017; Kazanavičius e Mažeika, 2023). 

  Diante desse cenário, a problemática central desta pesquisa reside na necessidade de compreender como os diferentes padrões de comunicação se comportam em um ambiente controlado e reprodutível. A relevância do problema é acentuada pelo fato de que, à medida que o número de serviços em uma arquitetura cresce, aumentam os custos de integração, os pontos de acoplamento e a sensibilidade do sistema a gargalos de comunicação. Embora existam estudos anteriores sobre o tema, ainda é necessário testar essas tecnologias em recortes específicos de plataforma, infraestrutura e carga para fornecer subsídios mais precisos às decisões arquiteturais. 

  Assim, este trabalho buscou produzir evidências experimentais para apoiar decisões arquiteturais no ecossistema .NET 8, mantendo equivalência funcional entre os protótipos e controle sobre as principais variáveis do benchmark. O objetivo geral foi comparar o comportamento de desempenho (latência e vazão) e discutir as implicações técnicas e operacionais dos padrões REST, gRPC e RabbitMQ em microsserviços com .NET, respeitando a semântica de cada paradigma: round-trip nos modos síncronos e, no modo assíncrono, tanto a latência de publicação quanto a latência fim a fim. 

2. Material e Métodos

  A pesquisa realizada é de natureza aplicada e explicativa, buscando oferecer subsídios para decisões arquiteturais e compreender como diferentes padrões de comunicação afetam o comportamento de sistemas distribuídos. A abordagem metodológica adotada foi quantitativa, fundamentada na coleta e análise de métricas de desempenho, como latência e vazão, e empregou um procedimento experimental controlado para manipular a variável independente. 

  O estudo comparou o comportamento de três padrões de comunicação – REST, gRPC e RabbitMQ – em um arranjo de microsserviços implementado no ecossistema .NET 8. O objetivo foi medir latência e vazão (throughput), com métricas adaptadas ao modelo de interação de cada paradigma, mantendo constantes as variáveis de processamento e o ambiente de execução para isolar o efeito do padrão de comunicação. 

  A arquitetura de referência foi composta por dois componentes funcionais principais: um API Gateway, atuando como ponto de entrada e produtor de requisições, e um Processing Service, responsável por simular a lógica de negócio. Nos cenários síncronos, o Processing Service retornava uma confirmação ao Gateway; no cenário assíncrono, processava a mensagem de forma desacoplada. 

  Para a implementação dos protótipos, utilizou-se o .NET 8 LTS (ASP.NET Core) devido à sua maturidade técnica e suporte nativo a HTTP/2, gRPC e integração com RabbitMQ. No cenário gRPC, os contratos foram definidos em Protocol Buffers (order.proto), e o cliente e servidor foram implementados com as bibliotecas Grpc.Net.Client e Grpc.AspNetCore, utilizando transporte sobre HTTP/2. 

  No cenário assíncrono, empregou-se o broker RabbitMQ, baseado no protocolo AMQP 0-9-1 (Vinoski, 2006). O produtor reutilizou uma conexão RabbitMQ pré-inicializada e canais AMQP para publicação concorrente. O experimento foi executado em modo fire-and-forget, com exchange direct, mensagens persistentes e publisher confirms desabilitado, priorizando a vazão de publicação no gateway. O consumidor RabbitMQ foi configurado com prefetchCount=1 e instância única, processando uma mensagem por vez. 

  A infraestrutura de execução foi definida via Docker Compose, garantindo que todos os componentes – Gateway, Processing Service e RabbitMQ – compartilhassem a mesma rede virtual isolada, minimizando a variabilidade por fatores externos de rede. A presença do gateway também representou um arranjo comum em microsserviços, embora possa introduzir riscos de gargalo se mal dimensionado (Taibi et al., 2018). 

  O ambiente operacional incluiu Docker Engine 29.3.1 e Docker Compose v5.1.0, executados em um host com Windows 11 Pro, CPU AMD Ryzen 7 7735HS e 32,0 GB DDR5 de RAM. Os componentes de software utilizados foram: Runtime .NET 8 LTS (ASP.NET Core), SDK mcr.microsoft.com/dotnet/sdk:8.0, Runtime image mcr.microsoft.com/dotnet/aspnet:8.0, RabbitMQ rabbitmq:3.13-management-alpine, RabbitMQ.Client 6.8.1, Grpc.Net.Client 2.65.0 e Google.Protobuf 3.28.3. A rede Docker utilizada foi uma bridge isolada (bench-net). 

  Para garantir a comparabilidade e reduzir vieses, foram implementados controles experimentais. Um atraso sintético determinístico de 10 ms (await Task.Delay(10)) foi inserido no Processing Service para simular um custo de processamento/I/O padronizado (Newman, 2021). O payload de transferência (OrderRequest) foi padronizado com 2048 caracteres alfanuméricos, gerados no Gateway, para exercer pressão sobre serialização e tráfego, conforme a literatura sobre benchmarks (Çiftçi e Çiloğlugil, 2025). 

  A geração de carga foi realizada com o Apache JMeter 5.6.3, executado via Docker. Foram conduzidas cinco execuções independentes para cada um dos quatro cenários avaliados: REST, gRPC, RabbitMQ original e RabbitMQ escalado. Cada execução envolveu 10 threads (usuários virtuais), um ramp-up de 5 segundos e 10.244 iterações por thread, totalizando 102.440 amostras por run e 512.200 amostras por modo. 

  Para mitigar a contaminação por compilação JIT do .NET, um ciclo de warm-up de 500 requisições foi implementado antes de cada execução, com descarte das amostras iniciais. Entre as execuções de cada cenário, o Gateway e o Processing Service foram reinicializados via Docker Compose, com um intervalo de estabilização de 10 segundos. O ResultCollector foi resetado e a drenagem completa da fila do RabbitMQ foi verificada. 

  A coleta de dados focou em métricas de desempenho sob carga. Para os cenários síncronos (REST e gRPC), a latência e vazão foram medidas diretamente pelo Apache JMeter. No cenário RabbitMQ, a latência de publicação foi medida pelo JMeter, enquanto a latência fim a fim foi coletada por um microsserviço dedicado, o ResultCollector. Essa distinção foi crucial, pois a latência no gateway não representa o tempo total de processamento no consumidor (Newman, 2021). 

  O ResultCollector registrou a latência fim a fim exclusivamente para o modo RabbitMQ. Ele capturou um timestamp no Gateway (createdAt) no recebimento da requisição e outro no Consumer (processedAt) após o processamento da mensagem e aplicação do atraso sintético. A latência foi calculada pela diferença simples e o resultado enviado via HTTP POST ao ResultCollector, que armazenou as medições em memória. 

  A análise dos dados envolveu o cálculo de média, desvio padrão e intervalo de confiança de 95% para as métricas de latência e vazão. Os intervalos de confiança foram calculados com distribuição t de Student (gl = 4). Os percentis p50 (mediana), p95 e p99 foram calculados pelo método nearest-rank sobre a lista ordenada de latências, conforme recomendado para captar variações em ambientes distribuídos (Newman, 2021). 

  Os experimentos foram conduzidos em ambiente local controlado, com as coletas ocorrendo entre 18 e 19 de março de 2026. A pesquisa dispensa submissão e registro no sistema CEP/CONEP, conforme as isenções da Resolução CNS nº 510/2016, por não envolver seres humanos e utilizar exclusivamente dados artificiais e inanimados para simulação de carga, sem risco de exposição de informações sensíveis. 

3. Resultados e Discussão

  Os resultados experimentais obtidos na avaliação comparativa entre os padrões de comunicação REST, gRPC e RabbitMQ em microsserviços .NET revelaram nuances importantes de desempenho e implicações operacionais. As análises foram fundamentadas em métricas de latência, incluindo p50 (mediana), p95 e p99, além de vazão (throughput) e taxa de erro, conforme os dados gerados pelo Apache JMeter. Para o RabbitMQ, foi crucial distinguir a latência de publicação (publish latency), medida no Gateway, da latência fim a fim, mensurada separadamente por um serviço coletor de resultados. Essa distinção é fundamental para a interpretação correta do comportamento assíncrono. 

  O experimento foi conduzido com parâmetros padronizados para garantir a comparabilidade dos cenários. Cada um dos modos testados – REST, gRPC, RabbitMQ original e RabbitMQ escalado – passou por cinco execuções independentes, precedidas por um warm-up de 500 requisições. A carga foi gerada por 10 threads, com 10.244 iterações por thread, totalizando 102.440 amostras por execução. O payload foi padronizado em 2.048 caracteres, e um atraso sintético de 10 ms foi inserido no serviço de processamento para simular uma carga de trabalho real, como detalhado na metodologia. 

  Para o modo REST, as cinco execuções registraram uma taxa de erro de 0,0%, indicando alta estabilidade. O throughput médio observado foi de 706,6 requisições por segundo, com um intervalo de confiança de 95% entre 700,1 e 713,1 req/s. A latência p50 (mediana) manteve-se estável em 13 ms em todas as execuções, enquanto a latência p95 foi de 16 ms e a p99 média atingiu 19,4 ms, com um intervalo de confiança de 95% entre 18,0 e 20,8 ms. A média geral de latência para REST foi de 13,63 ms, com um intervalo de confiança de 95% entre 13,49 e 13,76 ms. 

  O gRPC demonstrou um comportamento de desempenho muito próximo ao REST. As cinco execuções também apresentaram 0,0% de taxa de erro e um throughput médio de 694,3 requisições por segundo, com intervalo de confiança de 95% entre 690,3 e 698,4 req/s. A latência p50 foi de 14 ms, p95 de 16 ms e p99 de 17 ms, sem variação entre as execuções. A média de latência para gRPC foi de 13,87 ms, com um intervalo de confiança de 95% entre 13,81 e 13,93 ms. Embora os intervalos de confiança de 95% para throughput não se sobreponham, a diferença absoluta foi de apenas 1,7%, o que sugere uma equivalência prática no arranjo testado. 

  A proximidade de desempenho entre REST e gRPC, com medianas de latência de 13 ms e 14 ms, respectivamente, e uma diferença de throughput de apenas 1,7%, é um achado relevante. Essa paridade sugere que a camada de Gateway HTTP intermediária, presente no arranjo arquitetural, pode ter absorvido as diferenças intrínsecas dos protocolos, tornando-as menos perceptíveis do ponto de vista do cliente. O uso de HTTP/2 pelo gRPC, que permite multiplexação, não se traduziu em um ganho de desempenho significativo neste recorte específico, onde a lógica de negócio era simples e o payload padronizado. 

  No cenário RabbitMQ com consumidor único e `prefetchCount=1`, o throughput médio de publicação foi significativamente maior, atingindo 1.614,6 requisições por segundo, com um intervalo de confiança de 95% entre 1.500,9 e 1.728,3 req/s. A latência de publicação (medida no Gateway) teve uma mediana de 2,4 ms e um p99 de 23,2 ms, com intervalo de confiança de 95% entre 14,6 e 31,8 ms. Essa alta vazão e baixa latência de publicação indicam que o broker aceita mensagens rapidamente, o que é característico do modelo fire-and-forget, onde a resposta ao cliente é imediata após o enfileiramento da mensagem. 

  Contudo, a latência de publicação no RabbitMQ não reflete o tempo total de processamento. A latência fim a fim, medida pelo ResultCollector desde a entrada no Gateway até a conclusão do processamento no consumidor, revelou um comportamento distinto. No cenário com consumidor único, a mediana da latência fim a fim foi de 651.649 ms, o que equivale a aproximadamente 10,9 minutos. O p95 atingiu 1.197.207 ms, e o p99 foi de 1.243.097 ms. Esses valores elevados evidenciam um acúmulo substancial de mensagens na fila, pois a taxa de publicação superou amplamente a capacidade de consumo do serviço. 

  A alta latência fim a fim no cenário RabbitMQ original não indica uma lentidão inerente à ferramenta, mas sim a dinâmica do paradigma assíncrono quando há um desequilíbrio entre a taxa de produção e a capacidade de consumo. O consumidor, configurado para processar uma mensagem por vez com um atraso sintético de 10 ms, não conseguiu acompanhar o ritmo de publicação do Gateway, resultando na formação de um backlog. Esse achado corrobora a literatura que aponta a importância de monitorar a relação entre taxa de entrada e capacidade de processamento em sistemas de mensageria (Newman, 2021). 

  Em um cenário exploratório com RabbitMQ escalado, utilizando três consumidores e `prefetchCount=10`, a latência fim a fim foi drasticamente reduzida. A mediana caiu para 203.571 ms (cerca de 3,4 minutos), o p95 para 358.447 ms e o p99 para 367.420 ms. Essa redução de 69% na mediana da latência fim a fim demonstra que o acúmulo de fila é diretamente dependente da capacidade de consumo e da configuração do sistema de mensageria, e não uma limitação intrínseca do RabbitMQ. Observou-se também que o throughput de publicação no cenário escalado foi superior ao original, possivelmente devido à redução da fila acumulada e alívio da pressão de I/O de disco. 

  A comparação entre os modos síncronos e assíncronos, mediada por um Gateway HTTP, revela que a superioridade de uma tecnologia não é uma propriedade intrínseca, mas sim do arranjo arquitetural e operacional. A paridade entre REST e gRPC, por exemplo, contrasta com estudos como o de Niswar et al. (2024), que observaram vantagens significativas do gRPC em cenários sem gateway intermediário. Isso sugere que a camada de entrada comum pode diluir as diferenças de protocolo, tornando a escolha entre REST e gRPC mais dependente de fatores como ecossistema e manutenibilidade do que de ganhos de desempenho em latência ou vazão. 

  Do ponto de vista operacional, a adoção do RabbitMQ introduz uma camada adicional de complexidade. Requer a gestão de um broker dedicado, configuração de exchanges, filas e bindings, além de estratégias para tratamento de idempotência no consumidor e monitoramento do dreno da fila. Em contraste, REST e gRPC, por operarem sem middleware externo obrigatório, tendem a simplificar a implantação, observabilidade e diagnóstico de falhas. Esses trade-offs de complexidade técnica e custos operacionais são cruciais na decisão arquitetural, como apontado por Laigner et al. (2025) e Cerny et al. (2023). 

  A alta latência fim a fim do RabbitMQ no cenário original, embora pareça um resultado negativo, ilustra a capacidade dos sistemas de mensageria de absorver picos de carga e desacoplar temporalmente produtor e consumidor. A resposta rápida no gateway, seguida por um processamento posterior, permite que o sistema continue aceitando requisições mesmo quando os consumidores estão sobrecarregados. No entanto, essa característica exige um monitoramento rigoroso da fila e da capacidade de consumo para evitar que o backlog se torne insustentável, impactando a experiência do usuário final que espera a conclusão do processamento. 

  Os resultados obtidos neste experimento, portanto, reforçam a ideia de que a escolha do padrão de comunicação deve ser contextualizada. Não há um “vencedor” universal entre REST, gRPC e RabbitMQ; a decisão depende dos requisitos específicos do sistema, do perfil de carga, da infraestrutura disponível e da maturidade da equipe para operar cada tecnologia. A presença de um API Gateway, o tamanho do payload e a simulação de atraso sintético foram fatores controlados que influenciaram os achados, limitando a generalização para outros contextos, mas fornecendo evidências valiosas para o recorte arquitetural adotado. 

  Em síntese, a pesquisa demonstrou que, em um arranjo com Gateway HTTP intermediário, REST e gRPC apresentaram desempenho síncrono muito similar em termos de latência e vazão. O RabbitMQ, por sua vez, ofereceu alta vazão de publicação e baixa latência no gateway, mas exigiu atenção à latência fim a fim, que se mostrou elevada com consumidor único devido ao acúmulo de mensagens. A escalabilidade dos consumidores no RabbitMQ mitigou significativamente essa latência fim a fim, evidenciando que a eficácia do paradigma assíncrono depende criticamente do balanceamento entre produção e consumo. Os achados sublinham que a superioridade de uma tecnologia de comunicação não é intrínseca, mas sim um reflexo do arranjo arquitetural e operacional em que é empregada, respondendo ao objetivo de comparar o comportamento de desempenho e discutir as implicações técnicas e operacionais de cada padrão. 

4. Conclusão

  Este estudo buscou comparar o comportamento de desempenho, em termos de latência e vazão, e discutir as implicações técnicas e operacionais dos padrões REST, gRPC e RabbitMQ em microsserviços .NET 8, mediado por um Gateway HTTP intermediário, respeitando a semântica de cada paradigma. Verificou-se que, no arranjo arquitetural adotado, REST e gRPC apresentaram desempenho síncrono muito similar, com medianas de latência de 13 ms e 14 ms, e uma diferença de throughput de apenas 1,7%. Essa proximidade sugere que a camada de Gateway HTTP pode ter absorvido as diferenças intrínsecas dos protocolos, tornando-as menos perceptíveis do ponto de vista do cliente. O RabbitMQ, operando em modo fire-and-forget, registrou alta vazão de publicação de 1.614,6 requisições por segundo e baixa latência de 2,4 ms no gateway. Contudo, a latência fim a fim com consumidor único atingiu uma mediana de 651.649 ms, evidenciando um acúmulo substancial de mensagens na fila. A escalabilidade do RabbitMQ, com três consumidores e prefetchCount de dez, reduziu essa mediana da latência fim a fim em 69%, demonstrando que a eficácia do paradigma assíncrono depende criticamente do balanceamento entre produção e consumo. Os achados demonstraram que a superioridade de uma tecnologia de comunicação não é uma propriedade intrínseca, mas sim um reflexo do arranjo arquitetural e operacional em que é empregada, fornecendo evidências experimentais para decisões arquiteturais no ecossistema .NET 8. 

  As limitações do estudo incluem a execução em ambiente Docker local, o uso de payload fixo de 2.048 caracteres, carga constante de dez threads e a ausência de cenários com falhas parciais ou retries. A alteração simultânea do número de consumidores e do prefetchCount no cenário escalado do RabbitMQ impede a atribuição causal isolada dos efeitos de cada variável. Para estudos futuros, sugere-se variar esses parâmetros, isolar o efeito de cada variável na escalabilidade do RabbitMQ e replicar o experimento em uma rede distribuída real, com a inclusão de métricas de infraestrutura. Adicionalmente, o aumento do número de execuções pode fortalecer a inferência estatística, contribuindo para uma compreensão mais aprofundada dos trade-offs de desempenho e operacionais em diferentes contextos. 

Referências Bibliográficas

Cerny, T.; Abdelfattah, A.S.; Al Maruf, A.; Janes, A.; Taibi, D. 2023. Catalog and detection techniques of microservice anti-patterns and bad smells: a tertiary study. Journal of Systems and Software 206: 111829. DOI: 10.1016/j.jss.2023.111829.

Dragoni, N.; Giallorenzo, S.; Lafuente, A.L.; Mazzara, M.; Montesi, F.; Mustafin, R.; Safina, L. 2017. Microservices: yesterday, today, and tomorrow. p. 195-216. In: Mazzara, M.; Meyer, B. Present and Ulterior Software Engineering. Springer, Cham, Switzerland. DOI: 10.1007/978-3-319-67425-4_12.

Fernandes, J.L.; Lopes, I.C.; Rodrigues, J.J.P.C.; Ullah, S. 2013. Performance evaluation of RESTful web services and AMQP protocol. In: Fifth International Conference on Ubiquitous and Future Networks, 2013. Anais… p. 810-815. DOI: 10.1109/ICUFN.2013.6614932.

Fowler, M.; Lewis, J. 2014. Microservices: a definition of this new architectural term. Disponível em: https://martinfowler.com/articles/microservices.html. Acesso em: 18 mar. 2026.

Hong, X.J.; Yang, H.S.; Kim, Y.H. 2018. Performance analysis of RESTful API and RabbitMQ for microservice web application. In: International Conference on Information and Communication Technology Convergence, 2018. Anais… p. 257-259. DOI: 10.1109/ICTC.2018.8539409.

Kazanavičius, J.; Mažeika, D. 2023. The evaluation of microservice communication while decomposing monoliths. Computing and Informatics 42(1): 1-36. DOI: 10.31577/cai_2023_1_1. Disponível em: https://www.cai.sk/ojs/index.php/cai/article/view/2023_1_1. Acesso em: 18 mar. 2026.

Laigner, R.; Almeida, A.C.; Assunção, W.K.G.; Zhou, Y. 2025. An empirical study on challenges of event management in microservice architectures. ACM Transactions on Software Engineering and Methodology. DOI: 10.1145/3776581. Disponível em: https://dl.acm.org/doi/10.1145/3776581. Acesso em: 18 mar. 2026.

Newman, S. 2021. Building Microservices: Designing fine-grained systems. 2ed. O’Reilly Media, Sebastopol, CA, USA.

Niswar, M.; Safruddin, R.A.; Bustamin, A.; Aswad, I. 2024. Performance evaluation of microservices communication with REST, GraphQL, and gRPC. International Journal of Electronics and Telecommunications 70(2): 429-436. DOI: 10.24425/ijet.2024.149562.

Resolução CNS nº 510, 2016 [Referência completa não encontrada no documento original]

Richardson, C. 2018. Microservices Patterns: With examples in Java. Manning, Shelter Island, NY, USA.

Taibi, D.; Lenarduzzi, V.; Pahl, C. 2018. Architectural patterns for microservices: a systematic mapping study. In: Proceedings of the 8th International Conference on Cloud Computing and Services Science, 2018. Anais… p. 221-232. DOI: 10.5220/0006798302210232.

Vinoski, S. 2006. Advanced message queuing protocol. IEEE Internet Computing 10(6): 87-89. DOI: 10.1109/MIC.2006.116.

Çiftçi, B.; Çiloğlugil, B. 2025. A review of comparative studies on performance evaluation of communication mechanisms for microservices. p. 98-113. In: Gervasi, O. et al. Computational Science and Its Applications ICCSA 2025. Springer Nature Switzerland, Cham, Switzerland. DOI: 10.1007/978-3-031-96962-1_7.

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