🎯 Saiba o que estudar

Avançado com Treinador a partir de R$ 0,76/dia

Em arquiteturas de microsserviços voltadas para tribunais, a...

Próximas questões
Com base no mesmo assunto
Ano: 2026 Banca: FGV Órgão: TJ-SC Prova: FGV - 2026 - TJ-SC - Analista de Sistemas |
Q4150979 Arquitetura de Software
Em arquiteturas de microsserviços voltadas para tribunais, a comunicação baseada em mensageria (como o uso de Message Brokers) é frequentemente adotada para aumentar a resiliência do ecossistema.

Ao utilizar um modelo de comunicação assíncrona para o processamento de petições e atos processuais, o sistema busca mitigar o risco de falhas em cascata e lidar com picos de demanda.

Uma característica fundamental e intrínseca a esse modelo de interação é o
Alternativas

Gabarito comentado

Confira o gabarito comentado por um dos nossos professores

Gabarito: C

Fundamento decisivo: A questão pedia identificar a característica intrínseca da comunicação assíncrona por mensageria usada para resiliência e para lidar com picos de demanda.

Tema central: mensageria assíncrona
Análise das alternativas
A
Errada
Está errada porque afirma acoplamento temporal, exigindo que o destino esteja operacional no exato momento do envio. Isso contraria a característica da mensageria assíncrona, que justamente reduz essa dependência temporal.
B
Errada
Está errada porque descreve bloqueio da thread do emissor até confirmação de recebimento e processamento final pelo consumidor. Esse comportamento é típico de interação síncrona ou dependente de resposta, não da emissão assíncrona por broker.
C
Certa
A alternativa C está correta porque descreve a propriedade essencial da comunicação assíncrona baseada em mensageria em microsserviços: desacoplamento temporal e, tipicamente, espacial. O produtor envia ou publica a mensagem e continua seu fluxo de execução sem depender de o consumidor estar ativo naquele instante e sem necessidade de interação direta imediata com ele, o que é compatível com o uso de broker para aumentar resiliência.
D
Errada
Está errada porque troca mensageria assíncrona por RPC. RPC busca mimetizar chamada de função local em padrão de invocação remota e não define a característica fundamental pedida na questão.
E
Errada
Está errada porque atribui à camada de transporte uma garantia obrigatória, nativa e automática de idempotência. Pela base, idempotência não é intrínseca ao modelo nem universalmente garantida pelo transporte; depende do desenho da solução e da lógica de consumo/processamento.
Pegadinha da questão
A confusão explorada foi tratar comunicação assíncrona como se exigisse confirmação imediata, disponibilidade instantânea do consumidor ou semântica de RPC, além de sugerir idempotência automática pelo broker.
Dica para questões semelhantes
  • Se a alternativa exigir que o destinatário esteja disponível no instante do envio, isso aponta para acoplamento temporal, não para mensageria assíncrona.
  • Se o emissor precisa esperar confirmação ou processamento final para seguir, a descrição é de comportamento síncrono, não de característica intrínseca do modelo assíncrono.
  • Em questões sobre broker e resiliência, procure a ideia de o produtor publicar e prosseguir sem depender da localização ou da disponibilidade imediata do consumidor.
  • Não trate idempotência como garantia automática da camada de transporte, salvo se a própria base da questão disser isso expressamente.

Clique para visualizar este gabarito

Visualize o gabarito desta questão clicando no botão abaixo

Comentários

Veja os comentários dos nossos alunos

Desacoplamento Espacial: Em uma arquitetura orientada a mensagens, o Produtor não faz a menor ideia de quem é o Consumidor. Ele não sabe o endereço IP, não sabe em qual servidor ele está rodando, nem quantos consumidores existem. O Produtor apenas conhece o Broker (o "correio"). O Broker é quem gerencia a localização e a entrega, eliminando o acoplamento de rede (espacial) entre os microsserviços.

Desacoplamento Temporal: Significa independência no tempo. Se o microsserviço de "Processamento de Petições" (Consumidor) cair ou estiver em manutenção, o sistema não para. O microsserviço de "Recepção" (Produtor) continua recebendo petições do usuário e enviando para a fila. As mensagens ficam guardadas em segurança pelo Broker. Quando o consumidor voltar ao ar (mesmo que horas depois), ele retoma o processamento de onde parou. Essa é a principal arma contra falhas em cascata.

Picos de Demanda (Load Leveling / Buffering): O enunciado cita o tratamento de picos. Como a comunicação é assíncrona, se entrarem 10.000 petições de uma vez, o consumidor não é sobrecarregado (o que causaria lentidão ou travamento e estouro de memória). A fila atua como um amortecedor (buffer), e o consumidor processa as mensagens no seu próprio ritmo estrutural.

Comunicação Síncrona vs. Assíncrona:

  • Síncrona (Ex: REST/HTTP, RPC): O cliente envia e fica travado esperando a resposta do servidor. Se o servidor demorar, o cliente dá Timeout.

  • Assíncrona (Ex: AMQP, RabbitMQ, Kafka): O cliente envia (dispara) e vai fazer outra coisa. A resposta (se necessária) virá em um fluxo separado no futuro.

Clique para visualizar este comentário

Visualize os comentários desta questão clicando no botão abaixo