30 de julho de 2026
Comparação experimental entre comunicação síncrona via REST e assíncrona via Kafka em microsserviços
Felipe Wagner; Ana Beatriz Lopes Françoso
DOI: 10.22167/2675-6528-202600823
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 baseadas em microsserviços ressaltou a importância da escolha da forma de comunicação entre serviços, especialmente em fluxos transacionais que demandam rapidez e capacidade de processamento sob carga. A comunicação síncrona oferece simplicidade e previsibilidade, enquanto a assíncrona pode reduzir o acoplamento temporal e melhorar o tempo de resposta percebido pelo cliente. Este estudo comparou experimentalmente o desempenho da comunicação síncrona via REST e assíncrona via Apache Kafka em um fluxo de pedidos implementado com dois microsserviços desenvolvidos em Spring Boot. A pesquisa, de natureza aplicada e abordagem quantitativa, utilizou testes de carga no Apache JMeter 5.6.3, avaliando três cenários: fluxo completo via REST, aceite imediato via Kafka e processamento ponta a ponta assíncrono. Foram realizadas 57 execuções com diferentes cargas de usuários virtuais. Os resultados indicaram que, no fluxo REST, a latência média variou de 522,55 ms a 526,58 ms. No aceite imediato via Kafka, a latência média ficou entre 6,55 ms e 7,55 ms, com vazão superior à do REST. Contudo, no processamento ponta a ponta via Kafka, a latência média variou de 2306,23 ms a 4611,62 ms. Concluiu-se que a comunicação assíncrona reduziu o tempo de resposta percebido e ampliou a capacidade de aceite, enquanto a comunicação síncrona apresentou menor latência na conclusão integral do fluxo avaliado.
Palavras-chave: Arquitetura orientada a eventos; Desacoplamento temporal; Latência; Sistemas distribuídos; Vazão.
1. Introdução
O uso de arquiteturas baseadas em microsserviços consolidou-se como uma alternativa relevante para o desenvolvimento de sistemas distribuídos, especialmente aqueles que demandam modularidade, autonomia de equipes e escalabilidade operacional. Em vez de concentrar todas as regras de negócio em uma única aplicação monolítica, essa abordagem distribui as responsabilidades em serviços menores e especializados. Tal fragmentação facilita a manutenção, a evolução incremental e a implantação independente dos componentes (NEWMAN, 2021; DRAGONI et al., 2017). Contudo, a comunicação entre esses serviços torna-se uma decisão arquitetural central, influenciando diretamente o comportamento do sistema sob carga e a necessidade de monitoramento, testes e coordenação entre os componentes distribuídos (WASEEM et al., 2021).
No contexto da comunicação entre microsserviços, dois estilos principais se destacam. O primeiro é a comunicação síncrona, frequentemente implementada por meio de interfaces de programação de aplicações (APIs) baseadas no padrão Representational State Transfer (REST). Nesse modelo, um serviço depende da resposta imediata de outro para concluir sua própria operação. Embora essa abordagem seja simples de compreender e adequada para fluxos de negócio que exigem retorno instantâneo, ela pode propagar latência ao longo da cadeia de chamadas e aumentar o acoplamento temporal entre os componentes (FIELDING, 2000; RICHARDSON, 2018).
O segundo estilo corresponde à comunicação assíncrona orientada a eventos, geralmente viabilizada por middlewares de mensageria, como o Apache Kafka. Nesta abordagem, o serviço de entrada publica um evento e responde imediatamente ao cliente, enquanto o processamento detalhado é realizado por consumidores especializados em segundo plano. Essa estratégia tem o potencial de reduzir o acoplamento temporal e ampliar a capacidade de absorção de carga. No entanto, ela também pode tornar a avaliação do desempenho menos trivial, pois o tempo de resposta percebido pelo cliente não coincide necessariamente com o tempo total necessário para a conclusão efetiva do fluxo de negócio (KREPS; NARKHEDE; RAO, 2011; TAIBI; LENARDUZZI; PAHL, 2018; KAZANAVIČIUS; MAŽEIKA, 2023; SHEHZADI et al., 2024).
Em sistemas de comércio eletrônico, esse dilema arquitetural manifesta-se de forma clara. O aceite rápido de um pedido pode melhorar a experiência do usuário e aumentar a capacidade de recebimento de requisições, mas não garante a mesma velocidade para a conclusão completa do processamento do pedido. Assim, a estratégia de comunicação que apresenta o melhor desempenho na borda do sistema pode não ser a mais adequada para a conclusão ponta a ponta do fluxo, o que amplifica a relevância do problema investigado sob a perspectiva de desempenho computacional. A escolha da tecnologia de comunicação deve ser analisada por métricas específicas de desempenho, e não apenas por uma preferência arquitetural genérica (NISWAR et al., 2024).
Diante desse cenário, este estudo partiu da hipótese de que a comunicação assíncrona via Kafka reduziria substancialmente o tempo de resposta percebido no serviço de entrada e ampliaria a capacidade de aceite sob carga, embora pudesse aumentar a latência total necessária para a conclusão do pedido. A pesquisa justifica-se pela necessidade de compreender os trade-offs de desempenho entre essas abordagens em um contexto prático de microsserviços. Assim, o objetivo deste trabalho foi comparar o desempenho da comunicação síncrona via REST e da comunicação assíncrona via Kafka em um fluxo de pedidos baseado em microsserviços, considerando métricas de latência, percentis de resposta, vazão e taxa de erro.
2. Material e Métodos
O presente estudo caracterizou-se como uma pesquisa aplicada, de abordagem quantitativa, com objetivos descritivos e explicativos. O delineamento metodológico adotado foi o experimental, conforme as diretrizes de Gil (2002) e Lakatos e Marconi (2003). Essa escolha permitiu a comparação controlada de diferentes estratégias de comunicação entre microsserviços, com base em medições objetivas de desempenho em um ambiente simulado.
Para a condução do experimento, desenvolveram-se dois microsserviços utilizando a plataforma Spring Boot. O primeiro, denominado `pedido-service`, foi responsável por receber as requisições HTTP, registrar os pedidos iniciais e encaminhar o fluxo de processamento conforme a estratégia de comunicação definida. O segundo microsserviço, nomeado `processamento-service`, executou as operações especializadas e atualizou o estado final do pedido no sistema.
A infraestrutura de suporte incluiu a execução do broker Apache Kafka em um container Docker, operando sobre o Windows Subsystem for Linux (WSL). Os microsserviços foram executados localmente em um ambiente Windows. A persistência dos dados dos pedidos e dos eventos processados foi gerenciada por um H2 Database em memória, garantindo um ambiente controlado e isolado para os testes de desempenho.
No cenário de comunicação síncrona, o `pedido-service` encaminhou a requisição diretamente ao `processamento-service` via REST. Nesse modelo, o `pedido-service` aguardou a finalização completa da operação no `processamento-service` antes de retornar uma resposta ao cliente solicitante. Essa abordagem representou um fluxo de processamento sequencial e acoplado temporalmente.
No cenário assíncrono, o `pedido-service` publicou um evento no tópico `pedido-criado` e retornou imediatamente ao cliente, sem aguardar o processamento subsequente. Posteriormente, o `processamento-service` consumiu esse evento, realizou seu processamento especializado e publicou um novo evento no tópico `pedido-processado`. Esse evento foi então consumido pelo `pedido-service` para a atualização final do estado do pedido.
Para a observabilidade e o apoio operacional durante a campanha experimental, foram empregados o Kafka UI, que permitiu o monitoramento de tópicos, mensagens e atrasos de consumo, e os endpoints de métricas e saúde providos pelo Spring Boot Actuator. Essas ferramentas foram essenciais para acompanhar o comportamento dos serviços e do broker Kafka durante as execuções dos testes de carga.
A variável independente do estudo foi a estratégia de comunicação entre os microsserviços, avaliada em três configurações distintas. A primeira, denominada REST, mediu o desempenho do fluxo completo síncrono no endpoint `POST /api/rest/pedidos`. A segunda, KAFKA_POST, mensurou apenas o tempo de aceite inicial no endpoint `POST /api/kafka/pedidos`. A terceira, KAFKA_E2E, avaliou o tempo total desde a criação do pedido até a confirmação final do status `PROCESSADO` no fluxo assíncrono.
As variáveis dependentes consideradas foram a latência média, a mediana, o percentil 95, a vazão em requisições ou transações por segundo e a taxa de erro. Para garantir a validade dos resultados, diversas variáveis de controle foram mantidas constantes, incluindo o hardware utilizado, as versões dos serviços, o broker Kafka, o payload das requisições, o ambiente de execução local e o plano de teste automatizado no JMeter.
Os procedimentos experimentais iniciaram-se com a validação funcional dos fluxos, realizada por meio de requisições manuais aos endpoints `POST http://localhost:8081/api/rest/pedidos`, `POST http://localhost:8081/api/kafka/pedidos` e `GET http://localhost:8081/api/pedidos/{id}`. Essa etapa preliminar assegurou a correta operação dos microsserviços e dos mecanismos de comunicação antes da aplicação dos testes de carga.
Após a validação funcional, os testes de carga foram executados utilizando o Apache JMeter 5.6.3. Um plano de teste foi estruturado especificamente para o estudo, parametrizando a carga e registrando os resultados em arquivos de saída. O JMeter foi configurado para gerar relatórios e consolidar as métricas de desempenho, conforme as recomendações da Apache Software Foundation (2024).
A campanha experimental foi organizada em duas etapas. Na campanha principal, realizaram-se três repetições para cada cenário e para três níveis de carga de usuários virtuais: 5, 10 e 20. Em seguida, uma campanha complementar de validação foi executada com dez repetições adicionais, utilizando 10 threads, mantendo os mesmos parâmetros de carga. No total, foram realizadas 57 execuções no JMeter.
Em todas as rodadas de teste, foram aplicados parâmetros específicos no JMeter: um `ramp_time` de 3 segundos, uma `duration` de 10 segundos e um `think_time` de 1000 ms. Adicionalmente, para o cenário KAFKA_E2E, a configuração de polling foi estabelecida com um intervalo de 250 ms e um limite de 20 ciclos, visando simular o tempo de espera pelo evento final.
Os dados brutos de desempenho foram armazenados em arquivos `.jtl` gerados pelo JMeter. Nos cenários REST e KAFKA_POST, a consolidação dos dados ocorreu diretamente a partir dos samplers que registraram a criação bem-sucedida dos pedidos. Para o cenário KAFKA_E2E, a medição foi reconstruída a partir do intervalo entre a criação do pedido e a validação final do status `PROCESSADO`, permitindo o registro de transações incompletas ao final da janela de teste.
A análise considerou apenas as transações completas e bem-sucedidas. Para cada combinação de cenário e carga, calcularam-se a latência média, mediana, o percentil 95, a vazão e a taxa de erro. Nos pontos de 5 e 20 threads, os valores finais corresponderam à média das três repetições da campanha principal. No ponto de 10 threads, os valores finais resultaram da consolidação de 13 repetições, incluindo a validação complementar.
Como principal mecanismo de controle da validade interna e reprodutibilidade, adotou-se a verificação explícita de `consumerLag=0` nos grupos `processamento-group` e `pedido-service` antes do início de cada nova rodada. Esse procedimento minimizou o risco de contaminação entre as execuções devido a um possível backlog residual no Kafka, especialmente no cenário KAFKA_E2E. Os artefatos do experimento foram preservados para rastreabilidade.
3. Resultados e Discussão
A comparação experimental entre comunicação síncrona via REST e assíncrona via Apache Kafka em um fluxo de pedidos, implementado com microsserviços em Spring Boot, revelou distinções significativas no desempenho sob diferentes cargas de usuários virtuais. Este estudo, de natureza aplicada e abordagem quantitativa, utilizou testes de carga no Apache JMeter 5.6.3, avaliando três cenários: fluxo completo síncrono via REST, aceite imediato assíncrono via Kafka (KAFKA_POST) e processamento ponta a ponta assíncrono via Kafka (KAFKA_E2E). Os resultados globais indicaram que a comunicação assíncrona foi superior para reduzir o tempo de resposta percebido na borda do sistema e ampliar a capacidade de aceite, enquanto a comunicação síncrona apresentou menor latência na conclusão integral do fluxo avaliado. Essa dualidade sublinha a complexidade da escolha arquitetural em sistemas distribuídos, onde diferentes métricas de desempenho podem apresentar comportamentos opostos.
No cenário de comunicação síncrona via REST, o sistema demonstrou um comportamento estável e previsível em todas as cargas de trabalho testadas, com uma taxa de erro de 0%. A latência média para o fluxo completo variou de 522,55 ms com 5 threads para 526,58 ms com 10 threads e 523,15 ms com 20 threads. Essa consistência na latência, mesmo com o aumento do número de usuários virtuais, sugere que o custo do processamento no serviço de destino foi refletido diretamente no tempo de resposta percebido pelo cliente. A vazão, por sua vez, cresceu de 3,3106 requisições por segundo para 12,7536 requisições por segundo, aproximadamente proporcional ao aumento da carga. Esse comportamento é característico de sistemas síncronos, onde a finalização da operação está diretamente ligada à requisição inicial, propagando a latência ao longo da cadeia de chamadas (RICHARDSON, 2018; NEWMAN, 2021).
Em contraste, o cenário KAFKA_POST, que mediu apenas o aceite inicial do pedido via comunicação assíncrona, apresentou um desempenho notavelmente superior em termos de tempo de resposta percebido, também com 0% de erro. A latência média neste cenário manteve-se consistentemente baixa, variando entre 6,55 ms e 7,55 ms, com medianas entre 2,00 ms e 2,38 ms, em todos os níveis de carga. Essa redução, próxima de 98,6% na latência média quando comparado ao fluxo síncrono, evidencia o benefício do desacoplamento temporal proporcionado pela arquitetura orientada a eventos. A vazão também superou a do REST em todos os níveis de carga, atingindo 18,5365 requisições por segundo com 20 threads. Isso indica uma capacidade ampliada de absorção de carga no ponto de entrada do sistema, melhorando a experiência do usuário ao receber uma resposta imediata (KREPS; NARKHEDE; RAO, 2011; TAIBI; LENARDUZZI; PAHL, 2018; KAZANAVIČIUS; MAŽEIKA, 2023).
No entanto, a análise do cenário KAFKA_E2E, que avaliou o tempo total para a conclusão do pedido de ponta a ponta via Kafka, revelou um comportamento distinto e também com 0% de erro. A latência média neste cenário foi consideravelmente maior do que no REST, crescendo de 2306,23 ms com 5 threads para 4611,62 ms com 20 threads. O valor consolidado para 10 threads foi de 3728,08 ms. Essa elevação na latência total reflete o custo adicional do encadeamento assíncrono completo, que envolve múltiplas etapas como publicação, persistência no broker, consumo, processamento especializado e uma nova publicação de evento para atualização do estado final do pedido. A sequência de eventos assíncronos, embora desacoplada, introduz uma fila interna que se torna mais sensível ao aumento da carga, resultando em maior tempo para a conclusão efetiva da transação, o que foi um achado crucial do estudo.
A comparação entre os cenários destaca o trade-off central investigado por este estudo: a comunicação assíncrona via Kafka foi superior para otimizar o tempo de resposta percebido na borda do sistema e aumentar a capacidade de aceite de requisições. Contudo, a comunicação síncrona via REST demonstrou menor latência para a conclusão integral do fluxo de negócio. Este padrão é consistente com a literatura que aponta a complexidade da avaliação de desempenho em sistemas assíncronos, onde o tempo de resposta ao cliente não corresponde necessariamente ao tempo total de processamento, e a fila interna pode ser um gargalo (WASEEM et al., 2021; SHEHZADI et al., 2024). A escolha da estratégia de comunicação, portanto, deve ser guiada por métricas de desempenho específicas e alinhadas ao contexto operacional, e não por uma preferência arquitetural genérica, conforme apontado por outros estudos comparativos (NISWAR et al., 2024).
Um achado importante que reforça a confiabilidade dos resultados foi a taxa de erro de 0% observada em todas as 57 execuções realizadas, em todos os cenários. Esse dado indica uma estabilidade operacional robusta do ambiente testado, garantindo que as variações de desempenho registradas são atribuíveis às estratégias de comunicação e não a falhas sistêmicas ou intermitências. Adicionalmente, a campanha complementar de validação, com dez repetições adicionais em 10 threads, confirmou as tendências observadas na campanha principal e reduziu o risco de que a interpretação tivesse sido influenciada por aquecimento do ambiente ou oscilação episódica. Os desvios da latência média na validação complementar foram de 13,53 ms no REST, 2,99 ms no KAFKA_POST e 40,40 ms no KAFKA_E2E, valores que não alteraram a interpretação comparativa dos cenários, consolidando a robustez dos achados experimentais e a reprodutibilidade do estudo.
A interpretação dos resultados deve considerar as limitações inerentes ao ambiente experimental utilizado, que foi projetado para controle e repetibilidade. Os testes foram executados em um ambiente local, com os microsserviços em Windows, o broker Kafka em container Docker sobre Windows Subsystem for Linux (WSL) e a persistência de dados em H2 Database em memória. Embora essa configuração tenha favorecido o controle das variáveis e a repetibilidade das medições, ela não reproduz integralmente um ambiente produtivo distribuído, que tipicamente envolve múltiplos nós, bancos de dados persistentes, redes dedicadas, balanceamento de carga e políticas avançadas de escalabilidade. Assim, os resultados obtidos fornecem evidências experimentais do comportamento observado no ambiente controlado deste estudo, mas não devem ser generalizados automaticamente para qualquer infraestrutura de produção sem validação adicional e estudos complementares em larga escala.
Em síntese, a pesquisa demonstrou que a comunicação assíncrona via Kafka é eficaz para otimizar o tempo de resposta percebido pelo cliente e expandir a capacidade de aceite de requisições no serviço de entrada, um aspecto crucial para a experiência do usuário em sistemas transacionais de alta demanda. No entanto, para a conclusão integral do fluxo de negócio, a comunicação síncrona via REST apresentou menor latência total. Essa dicotomia ressalta que a escolha da estratégia de comunicação entre microsserviços não é uma decisão universal, mas depende criticamente da métrica de desempenho prioritária para o negócio, seja a rapidez da resposta inicial ou a agilidade na finalização completa da operação. Os achados reforçam a necessidade de uma análise contextualizada para a tomada de decisão arquitetural, alinhando a tecnologia de comunicação aos requisitos específicos de desempenho do sistema.
4. Conclusão
Este estudo buscou comparar o desempenho da comunicação síncrona via REST e da comunicação assíncrona via Kafka em um fluxo de pedidos baseado em microsserviços, avaliando métricas de latência, percentis de resposta, vazão e taxa de erro. Verificou-se que a comunicação assíncrona, ao permitir o aceite imediato do pedido, reduziu substancialmente o tempo de resposta percebido pelo cliente e ampliou a capacidade de absorção de requisições no serviço de entrada. A latência média para o aceite imediato via Kafka situou-se entre 6,55 ms e 7,55 ms, representando uma redução próxima de 98,6% em comparação com o fluxo síncrono. Em contrapartida, observou-se que a comunicação síncrona via REST apresentou menor latência para a conclusão integral do fluxo de negócio, com médias entre 522,55 ms e 526,58 ms. O processamento ponta a ponta assíncrono via Kafka, por sua vez, demonstrou latência total superior, variando de 2306,23 ms a 4611,62 ms, refletindo o custo do encadeamento completo de eventos. A principal contribuição do trabalho reside na explicitação desse trade-off de desempenho, reforçando que a escolha da estratégia de comunicação entre microsserviços não deve ser universal, mas sim alinhada às métricas de desempenho prioritárias para o contexto operacional específico.
A interpretação desses resultados deve considerar as limitações do ambiente experimental, que foi configurado para controle e repetibilidade. Os testes foram executados em ambiente local, com microsserviços em Windows, broker Kafka em container Docker sobre WSL e persistência em H2 Database em memória. Embora essa configuração tenha favorecido a validação dos achados, ela não reproduz integralmente um ambiente produtivo distribuído, o que impede a generalização automática dos resultados para qualquer infraestrutura sem validação adicional. Como continuidade da pesquisa, sugere-se ampliar a coleta de métricas de Central Processing Unit e memória, variar o número de consumidores Kafka, utilizar banco de dados persistente e incluir cenários com falha e reprocessamento. Tais estudos futuros permitirão verificar se as tendências observadas permanecem em ambientes mais próximos de produção, consolidando a aplicabilidade das conclusões.
Referências Bibliográficas
APACHE SOFTWARE FOUNDATION. Apache JMeter – User’s Manual: Generating Dashboard Report. Disponível em: https://jmeter.apache.org/usermanual/generating-dashboard. Acesso em: 02 abr. 2026.
DRAGONI, Nicola et al. Microservices: yesterday, today, and tomorrow. In: MICALLEF, Anthony; ABRAHAMSSON, Pekka. Present and Ulterior Software Engineering. Cham: Springer, 2017. p. 195-216.
FIELDING, Roy Thomas. Architectural Styles and the Design of Network-based Software Architectures. Irvine: University of California, 2000. Doctoral dissertation.
GIL, Antonio Carlos. Métodos e técnicas de pesquisa social. 6. ed. São Paulo: Atlas, 2002.
KAZANAVIČIUS, Justas; MAŽEIKA, Dalius. Evaluation of microservice communication while decomposing monoliths. Computing and Informatics, v. 42, p. 1-36, 2023. DOI: 10.31577/cai_2023_1_1.
KREPS, Jay; NARKHEDE, Neha; RAO, Jun. Kafka: a distributed messaging system for log processing. In: Proceedings of the NetDB. Athens, 2011.
LAKATOS, Eva Maria; MARCONI, Marina de Andrade. Fundamentos de metodologia científica. 5. ed. São Paulo: Atlas, 2003.
NEWMAN, Sam. Building Microservices: Designing Fine-Grained Systems. 2. ed. Sebastopol: O’Reilly Media, 2021.
NISWAR, Muhammad; SAFRUDDIN, Reza Arisandy; BUSTAMIN, Anugrayani; ASWAD, Iqra. Performance evaluation of microservices communication with REST, GraphQL, and gRPC. International Journal of Electronics and Telecommunications, v. 70, n. 2, p. 429-436, 2024.
RICHARDSON, Chris. Microservices Patterns: With examples in Java. Shelter Island: Manning, 2018.
SHEHZADI, M.; CHAUDHRY, N. R.; ASLAM, A.; CHOUDHARY, R. Inter-process communication amongst microservices. Pakistan Journal of Scientific Research, v. 4, n. 1, p. 1-9, 2024.
TAIBI, Davide; LENARDUZZI, Valentina; PAHL, Claus. Architectural patterns for microservices: a systematic mapping study. In: Proceedings of the 8th International Conference on Cloud Computing and Services Science. Funchal: SciTePress, 2018. p. 221-232.
WASEEM, Muhammad; LIANG, Peng; SHAHIN, Mojtaba; DI SALLE, Amleto; MÁRQUEZ, Gastón. Design, monitoring, and testing of microservices systems: The practitioners’ perspective. Journal of Systems and Software, v. 182, 111061, 2021.
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
