Arquitetura de Software · TJ-PI · 2025 | Questão sqc-qg614915

Arquitetura de SoftwareSistemas Distribuídos

Código: qg614915
Banca: TJ-PI
Órgão: TJ-PI
Ano: 2025
Nível: Superior

Cargo: Residente Tecnológico

A equipe de desenvolvimento do TJPI está migrando funcionalidades do PJe para uma arquitetura de microsserviços. Um novo microsserviço, "Cálculo de Custas", precisa ser criado. Uma operação de negócio, como o "ajuizamento de uma ação", agora envolve chamadas a múltiplos serviços: (1) o serviço de "Protocolo" cria o registro do processo, (2) o serviço de "Cálculo de Custas" calcula o valor devido, e (3) o serviço de "Distribuição" atribui o processo a uma vara. Como garantir a consistência dos dados e a atomicidade dessa operação distribuída, sabendo que um commit de dois tempos (2PC) é considerado muito rígido e acopla fortemente os serviços?

AImplementar a lógica de todas as três etapas dentro de um único microsserviço monolítico para usar uma transação de banco de dados local (ACID), abandonando a abordagem de microsserviços para esta funcionalidade.
BUtilizar o Padrão Saga, onde cada serviço executa sua transação local e publica um evento. Em caso de falha em uma etapa subsequente, os serviços anteriores executam transações de compensação para reverter suas ações, garantindo a consistência eventual da operação de negócio.
CExigir que o cliente (a interface do usuário) orquestre as chamadas, sendo responsável por chamar cada serviço em sequência e por implementar a lógica de rollback em caso de falha.
DImplementar um mecanismo de retry (tentativa) agressivo. Se a chamada ao serviço de "Cálculo de Custas" falhar, o serviço de "Protocolo" deve tentar chamá-lo indefinidamente até que ele tenha sucesso.
EUtilizar um banco de dados distribuído com suporte a transações ACID multi-documento, como o MongoDB, e colocar os dados de todos os microsserviços neste único banco para garantir a consistência.

Revelar gabarito e comentário

GabaritoB — Utilizar o Padrão Saga, onde cada serviço executa sua transação local e publica um evento. Em caso de falha em uma etapa subsequente, os serviços anteriores executam transações de compensação para reverter suas ações, garantindo a consistência eventual da operação de negócio.

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”.

Garantindo consistência em operações distribuídas com microsserviços

Gabarito: letra B. O Padrão Saga resolve o problema de atomicidade em transações distribuídas sem o acoplamento do 2PC: cada serviço executa sua transação local e publica um evento; em caso de falha, os serviços anteriores executam transações de compensação para reverter as ações, garantindo consistência eventual.

A questão aborda o desafio de manter a atomicidade de uma operação de negócio que envolve múltiplos microsserviços, rejeitando o two-phase commit (2PC) por sua rigidez e acoplamento. A alternativa correta deve apresentar um padrão adequado para transações distribuídas em microsserviços.

Padrão / Abordagem	Descrição	Garante Atomicidade?	Adequado para Microsserviços?	Problema Principal
Padrão Saga (B)	Cada serviço executa transação local e publica evento; falha dispara compensações.	Sim (consistência eventual)	Sim	Nenhum (é a solução recomendada)
Monolito (A)	Unificar serviços em um único monolito com transação ACID local.	Sim (ACID)	Não	Abandona a arquitetura de microsserviços
Cliente Orquestrador (C)	Cliente chama serviços em sequência e implementa rollback.	Não (cliente não gerencia estado distribuído)	Não	Acoplamento e exposição de lógica interna
Retry Agressivo (D)	Tentativas infinitas em caso de falha.	Não	Não	Pode gerar inconsistência permanente
Banco Único Distribuído (E)	Dados de todos os serviços em um único banco com ACID.	Sim (ACID)	Não	Viola descentralização de dados

1Protocolo cria registro
2Cálculo de Custas calcula
3Distribuição atribui vara
4Falha em etapa N
5Compensação das anteriores

LEVEL · soulevel.com.br

Alternativa A — ❌ Incorreta

Propõe abandonar a arquitetura de microsserviços e voltar a um monolito, o que contraria o objetivo da migração e não resolve o problema dentro do contexto de microsserviços. A ideia é justamente manter a independência dos serviços.

Alternativa B — ✅ Correta ⟵ GABARITO

O Padrão Saga é a abordagem recomendada quando o 2PC é inviável. Cada serviço realiza sua transação local e, ao concluir, publica um evento que dispara a próxima etapa. Se uma etapa falha, os serviços que já concluíram executam transações de compensação (ex.: estornar um cálculo, cancelar um registro) para reverter o estado, mantendo a consistência eventual. Isso garante atomicidade sem acoplamento forte.

Alternativa C — ❌ Incorreta

Delegar ao cliente a orquestração das chamadas e o rollback é uma má prática: aumenta o acoplamento, duplica a lógica de negócio e expõe detalhes internos dos serviços ao cliente. O cliente não deve ser responsável pela coordenação transacional.

Alternativa D — ❌ Incorreta

Implementar retry agressivo indefinidamente não garante atomicidade nem consistência. Se o serviço de Cálculo de Custas falhar permanentemente, o processo nunca será concluído ou poderá deixar o sistema em estado inconsistente. Além disso, não há mecanismo de compensação para desfazer o registro já criado.

Alternativa E — ❌ Incorreta

Colocar todos os dados em um único banco de dados distribuído com suporte a transações ACID fere o princípio de descentralização de dados em microsserviços, onde cada serviço deve ter seu próprio banco de dados. Isso reintroduz o acoplamento forte que a arquitetura de microsserviços busca evitar, além de criar um ponto único de falha e gargalo de desempenho.

NÃO CAIA NESSA!

A banca explora a rejeição ao 2PC e testa o conhecimento do Padrão Saga. Cuidado para não confundir com soluções como orquestração pelo cliente ou retry simples, que não garantem consistência. O Saga é a alternativa correta por usar compensação.

Gabarito: letra B.

Link permanente: /questoes/qg614915