Questão de Arquitetura de Software — Sistemas Distribuídos — FEPESE 2026
Arquitetura de Software›Sistemas Distribuídos
Código
qg675731
Banca
FEPESE
Órgão
CIDASC
Ano
2026
Nível
Superior
Cargo
Analista de Tecnologia da Informação e Comunicação (Banco de Dados)
Em arquiteturas de microsserviços, a comunicação assíncrona é frequentemente utilizada. Um Message Broker (intermediário de mensagens) é um componente central nesse tipo de arquitetura.Qual é a principal função de um Message Broker como o RabbitMQ?
AArmazenar a configuração centralizada para todos os microsserviços.
BExpor um ponto de acesso único (API Gateway) para todos os microsserviços.
CDescobrir a localização de instâncias de serviços em um ambiente dinâmico (Service Discovery).
DReceber mensagens de um serviço (produtor), armazená-las em filas e entregá-las a um ou mais serviços (consumidores) de forma confiável.
EControlar o fluxo de requisições entre os serviços, implementando políticas de segurança e cache.
Revelar gabarito e comentário▾
GabaritoD — Receber mensagens de um serviço (produtor), armazená-las em filas e entregá-las a um ou mais serviços (consumidores) de forma confiável.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Message Broker (RabbitMQ) em Microsserviços
Gabarito: alternativa D. A principal função de um Message Broker como o RabbitMQ é atuar como intermediário confiável na comunicação assíncrona entre microsserviços, recebendo mensagens de serviços produtores, armazenando-as em filas e entregando-as a um ou mais consumidores. Ele garante o desacoplamento e a confiabilidade na entrega, mesmo que os consumidores estejam temporariamente indisponíveis.
A questão aborda o papel central de um Message Broker em arquiteturas de microsserviços, especialmente em comunicação assíncrona. Diferentemente de outros componentes como API Gateway, Service Discovery ou Config Server, o Message Broker foca no roteamento e entrega de mensagens.
Alternativa A — ❌ Incorreta
Armazenar configuração centralizada é função de um Config Server (ex.: Spring Cloud Config, Consul KV). O Message Broker lida com mensagens de aplicação, não com configuração de serviços.
Alternativa B — ❌ Incorreta
Expor um ponto de acesso único é papel de um API Gateway, que faz roteamento, balanceamento e segurança. O Message Broker não expõe APIs REST para os clientes; ele gerencia filas/tópicos internamente.
Alternativa C — ❌ Incorreta
Descobrir localização de instâncias de serviços é feito por ferramentas de Service Discovery como Eureka, Consul ou Kubernetes DNS. O Message Broker não tem funcionalidade de descoberta dinâmica de serviços.
Alternativa D — ✅ Correta ⟵ GABARITO
Exatamente a descrição clássica de um Message Broker (RabbitMQ, Apache Kafka, etc.): receber mensagens do produtor, armazená-las em filas e entregar aos consumidores de forma confiável (com confirmações, persistência e retentativas). Isso viabiliza comunicação assíncrona e desacoplamento entre microsserviços.
Alternativa E — ❌ Incorreta
Controlar fluxo, segurança e cache são responsabilidades de um API Gateway ou de um service mesh (sidecar proxy). O Message Broker não implementa políticas de segurança nem faz cache de requisições HTTP.
PEGA ESSA DICA!
Em questões de arquitetura, associe cada função a um componente específico: mensageria → Message Broker; roteamento/segurança → API Gateway; descoberta → Service Discovery; configuração → Config Server. Memorize essa relação e a resposta sai direta.