Questão de Arquitetura de Software — Sistemas Distribuídos — Quadrix 2025
Arquitetura de Software›Sistemas Distribuídos
Código
qg595974
Banca
Quadrix
Órgão
CRA-SP
Ano
2025
Nível
Superior
Cargo
Analista II - Desenvolvimento de Sistemas
Uma arquitetura de microsserviços precisou ser projetada para desacoplar os serviços. O serviço Pedidos deveria notificar os serviços Estoque e Notificações sempre que ocorresse uma nova venda. É um requisito crítico que o serviço Pedidos não falhe caso o serviço Notificações esteja temporariamente indisponível.Com base nessa situação hipotética, assinale a opção que apresenta o padrão de integração de sistemas que atende a esse requisito de desacoplamento e resiliência, utilizando um intermediário.
Achamada de procedimento remoto (RPC) síncrona
Btransferência de arquivos em lote (batch)
Cbanco de dados compartilhado
Dmensageria (Message Queue)
EAPI RESTful síncrona
Revelar gabarito e comentário▾
GabaritoD — mensageria (Message Queue)
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”.
Arquitetura de Microsserviços e Padrões de Integração
Gabarito: letra D. O padrão de mensageria (Message Queue) atende exatamente ao requisito: utiliza um intermediário (fila) para desacoplar os serviços, garantindo que o serviço Pedidos não falhe se Notificações estiver temporariamente indisponível — a mensagem fica retida na fila até o destinatário processá-la. Esse é um exemplo clássico de comunicação assíncrona, que promove resiliência e desacoplamento.
A banca testa o conhecimento sobre padrões de integração em microsserviços e a diferença entre comunicação síncrona e assíncrona. Vejamos cada alternativa:
Padrões de integração
1Síncronos (acoplamento forte)
RPC
API RESTful
2Assíncronos (desacoplamento)
Batch (arquivos)
Mensageria (Message Queue)
Intermediário (fila)
Mensagem retida até processamento
Resiliência
Desacoplamento
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
A chamada de procedimento remoto (RPC) síncrona exige que ambos os serviços estejam disponíveis no momento da chamada. Se Notificações estiver indisponível, Pedidos receberia uma exceção/erro e poderia falhar. Viola o requisito de resiliência.
Alternativa B — ❌ Incorreta
Transferência de arquivos em lote (batch) é assíncrona, mas não atende ao requisito de notificação em tempo real (a cada nova venda). Além disso, seria um mecanismo pesado e não é o padrão mais indicado para notificações entre microsserviços.
Alternativa C — ❌ Incorreta
Banco de dados compartilhado entre microsserviços gera acoplamento forte e viola o princípio de desacoplamento. Além disso, se o banco falhar, todos os serviços podem ser afetados. Não é o padrão que usa um intermediário de mensagens.
Alternativa D — ✅ Correta ⟵ GABARITO
Mensageria (Message Queue) utiliza um intermediário (fila de mensagens) entre o produtor (Pedidos) e os consumidores (Estoque, Notificações). A comunicação é assíncrona: Pedidos publica a mensagem na fila e continua seu processamento imediatamente, independentemente da disponibilidade de Notificações. Se Notificações estiver fora, a mensagem permanece na fila até que ele retorne. Isso garante desacoplamento e resiliência.
Alternativa E — ❌ Incorreta
API RESTful síncrona é semelhante ao RPC: Pedidos faria uma requisição HTTP para Notificações e aguardaria a resposta. Se Notificações estivesse indisponível, a requisição falharia, podendo comprometer Pedidos (a menos que haja um tratamento de erro complexo, mas ainda assim não é o padrão com intermediário).
Conclusão: o padrão que atende ao requisito é a mensageria, com fila de mensagens.
PEGA ESSA DICA!
Em questões de microsserviços, lembre-se: para desacoplamento e resiliência, prefira comunicação assíncrona (filas, mensageria) sobre síncrona (RPC, REST). A banca adora cobrar essa diferença.