Questão de Arquitetura de Software — Sistemas Distribuídos — FGV 2026
Arquitetura de Software›Sistemas Distribuídos
Código
fg129169
Banca
FGV
Órgão
AMAZUL
Ano
2026
Nível
Superior
Cargo
Engenheiro de Computação
Uma empresa está migrando sua arquitetura monolítica para microsserviços. Durante a análise, identificou-se que vários serviços precisam acessar dados de clientes, atualmente centralizados em um único banco de dados.Considerando os princípios de arquitetura de microsserviços e o teorema CAP, a abordagem mais adequada para garantir autonomia dos serviços, sem comprometer a consistência dos dados críticos de clientes é
Amanter o banco de dados compartilhado entre todos os serviços para garantir consistência forte.
Breplicar o banco de dados de clientes para cada microsserviço, garantindo que cada um tenha sua própria cópia completa
Cimplementar um serviço dedicado de clientes com seu próprio banco de dados e expor operações via API, usando eventos para sincronização eventual com outros serviços
Deliminar o banco de dados relacional e migrar todos os dados para um sistema de arquivos distribuído
Eimplementar transações distribuídas (2PC) entre todos os serviços para garantir atomicidade
Revelar gabarito e comentário▾
GabaritoC — implementar um serviço dedicado de clientes com seu próprio banco de dados e expor operações via API, usando eventos para sincronização eventual com outros serviços
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 Teorema CAP
Gabarito: letra C. Em microsserviços, cada serviço deve ter seu próprio banco de dados para garantir autonomia e desacoplamento. Para dados compartilhados (como clientes), a abordagem mais adequada é criar um serviço dedicado que exponha operações via API e use eventos para sincronização eventual, respeitando o teorema CAP ao priorizar disponibilidade e tolerância a partição sobre consistência forte.
A banca testa o conhecimento dos princípios de microsserviços e do trade-off do teorema CAP: consistência, disponibilidade e tolerância a partição. Em sistemas distribuídos, é impossível garantir os três simultaneamente. Microsserviços privilegiam disponibilidade e tolerância a partição, adotando consistência eventual.
1Serviço dedicado de clientes
2Banco próprio
3API para operações
4Eventos p/ sincronização eventual
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
Manter um banco de dados compartilhado entre todos os serviços viola o princípio de {{descentralização de dados}} essencial aos microsserviços. Isso cria acoplamento forte, perda de autonomia e dificulta a escalabilidade independente.
Alternativa B — ❌ Incorreta
Replicar o banco de dados completo para cada microsserviço gera redundância excessiva, problemas de sincronização e inconsistência. Além disso, cada serviço teria que gerenciar uma cópia, aumentando a complexidade e violando o princípio de {{fonte única de verdade}}.
Alternativa C — ✅ Correta ⟵ GABARITO
Criar um serviço dedicado de clientes com seu próprio banco de dados, expor operações via API e usar eventos para sincronização eventual atende aos princípios de microsserviços: autonomia, desacoplamento e consistência eventual. Essa abordagem respeita o teorema CAP ao abrir mão da consistência forte em favor de disponibilidade e tolerância a partição.
Alternativa D — ❌ Incorreta
Eliminar o banco relacional e migrar para um sistema de arquivos distribuído não resolve o problema de consistência e pode introduzir nova complexidade. Não é uma prática recomendada para dados críticos de clientes em microsserviços.
Alternativa E — ❌ Incorreta
Implementar transações distribuídas (2PC) compromete a disponibilidade e a escalabilidade, violando o teorema CAP ao tentar manter consistência forte. Microsserviços preferem consistência eventual e evitam 2PC por seu alto custo e complexidade.
NÃO CAIA NESSA!
A banca explora o conflito entre consistência forte (alternativas A e E) e autonomia dos serviços. Lembre-se: microsserviços favorecem {{descentralização de dados}} e {{consistência eventual}}. Transações 2PC são evitadas em arquiteturas distribuídas modernas.