Pular para o conteúdo principal

Questão de Arquitetura de Software — Arquitetura de Software — CESPE / CEBRASPE 2025

Arquitetura de SoftwareArquitetura de Software
Código
ce198454
Banca
CESPE / CEBRASPE
Órgão
EMBRAPA
Ano
2025
Nível
Superior
Cargo
Analista - Área: Ciências Exatas e da Terra - Subárea: Sistemas de Informação
Julgue o item subsequente, relacionado a arquitetura de software escalável e manutenível ao longo do tempo.Na arquitetura de microsserviços, a comunicação entre os serviços é sempre realizada de forma síncrona, o que garante a consistência dos dados.
  1. CCerto
  2. EErrado
Revelar gabarito e comentário

GabaritoE — Errado

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 — Comunicação e Consistência

ERRADO. A afirmação está incorreta porque, na arquitetura de microsserviços, a comunicação entre os serviços não é sempre síncrona — pode ser assíncrona (ex.: filas de mensagens, eventos) — e, mesmo quando síncrona, não garante automaticamente a consistência dos dados. O padrão mais comum é a consistência eventual, adotando estratégias como o Teorema CAP e transações distribuídas (Saga, TCC).

A banca explora dois erros clássicos: o uso do termo "sempre" (que nega a possibilidade de comunicação assíncrona) e a falsa relação de causalidade entre síncrono e consistência garantida. Em microsserviços, a consistência forte é difícil de alcançar e frequentemente sacrificada em prol da disponibilidade e da escalabilidade.

Análise do enunciado

❌ ERRADO — O item merece julgamento ERRADO, conforme gabarito oficial.

  • A palavra "sempre" é o primeiro sinal de alerta. Microsserviços se comunicam de forma síncrona (REST, gRPC) ou assíncrona (mensageria, eventos, streams). Não há obrigatoriedade de um único modo.

  • A garantia de consistência não decorre do tipo de comunicação. Comunicação síncrona pode falhar (timeout, erro) e dados podem ficar inconsistentes. Na prática, adota-se consistência eventual com mecanismos como eventual consistency, Sagas, ou eventos de domínio.

1Síncrona
REST, gRPC
Não garante consistência
2Assíncrona
Filas, eventos, streams
Consistência eventual
3Consistência
Forte (rara, sacrificada)
Eventual (padrão)
Teorema CAP
Padrões: Saga, CQRS
Comunicação em microsserviços
LEVELsoulevel.com.br
Comunicação em microsserviços: Síncrona (REST, gRPC, Não garante consistência); Assíncrona (Filas, eventos, streams, Consistência eventual); Consistência (Forte (rara, sacrificada), Eventual (padrão), Teorema CAP, Padrões: Saga, CQRS)
PEGA ESSA DICA!

Em provas, desconfie de afirmativas com "sempre", "nunca", "todo". Microsserviços são, por definição, descentralizados e flexíveis; a comunicação síncrona é uma opção, não uma regra. A consistência é um desafio que exige padrões específicos (ex.: Saga, CQRS).

Gabarito: E (Errado).

Link permanente: /questoes/ce198454