Quiz de Arquitetura

Resposta: B

A diferença fundamental é a implantação independente. Cada microsserviço pode ser implantado, escalado e atualizado sem afetar os demais. Um monolito é implantado como uma única unidade.

Os monolitos também conseguem escalar (verticalmente ou com múltiplas instâncias). Os microsserviços não são inerentemente mais rápidos — na verdade, a comunicação pela rede adiciona latência.

Resposta: C

O Dependency Inversion Principle (DIP) estabelece que:

1. Os módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações.
2. As abstrações não devem depender de detalhes. Os detalhes devem depender de abstrações.

Na prática, isso significa usar interfaces ou contratos entre camadas, e não dependências diretas de implementações concretas.

Resposta: B

Um monolito (especialmente um monolito modular) é uma excelente escolha quando:

• A equipe é pequena (< 8 pessoas)
• O domínio não está bem definido (os limites dos serviços vão mudar)
• A velocidade de desenvolvimento é mais importante do que a escalabilidade independente
• Você não tem a infraestrutura para operar sistemas distribuídos

Os microsserviços adicionam uma complexidade operacional significativa. Se você não precisa dela, não a adicione.

Resposta: B

O Circuit Breaker detecta quando um serviço externo está falhando ou respondendo lentamente e “abre o circuito” para parar de enviar requisições a ele. Isso evita que as threads fiquem bloqueadas esperando respostas que não chegam, protegendo seu sistema de uma cascata de falhas.

Estados do circuit breaker:

• Fechado: tudo funciona normalmente, as requisições passam
• Aberto: o serviço está falhando, as requisições são rejeitadas imediatamente
• Semiaberto: permite-se uma requisição de teste para verificar se o serviço se recuperou

Resposta: B

O Outbox Pattern resolve o problema da escrita dupla: quando você precisa atualizar o banco de dados E publicar um evento, e ambas as operações precisam ser atômicas.

Em vez de publicar diretamente no broker, você grava o evento em uma tabela “outbox” dentro da mesma transação de banco de dados. Um processo separado lê a tabela outbox e publica os eventos no broker. Se a publicação falhar, ela é reenviada. Se a transação falhar, o evento nunca foi gravado na outbox.

Resposta: C

CQRS (Command Query Responsibility Segregation) separa o modelo de leitura do modelo de escrita. Isso permite:

• Otimizar as leituras com modelos desnormalizados
• Escalar leituras e escritas de forma independente
• Usar diferentes bancos de dados para cada modelo

O CQRS não requer Event Sourcing, embora frequentemente sejam usados juntos.

Resposta: B

O backoff exponencial com jitter é a estratégia recomendada porque:

• Backoff exponencial: cada nova tentativa espera mais tempo (1s, 2s, 4s, 8s…), dando tempo ao serviço para se recuperar
• Jitter: adiciona um componente aleatório ao delay para evitar que todos os clientes tentem novamente ao mesmo tempo (thundering herd)
• Limite de tentativas: sempre defina um máximo (tipicamente 3-5 tentativas)

Retry imediato sem limite pode piorar o problema ao sobrecarregar um serviço que já está com dificuldades.

Resposta: B

Os três pilares da observabilidade são:

• Logs: registros textuais de eventos discretos (o que aconteceu)
• Métricas: valores numéricos agregados ao longo do tempo (quanto, quão rápido)
• Traces: rastreamento de uma requisição através de múltiplos serviços (por onde passou)

Juntos, permitem entender o comportamento de um sistema distribuído. Alertas, dashboards e relatórios são ferramentas que consomem esses dados, mas não são pilares em si.

Resposta: B

A diferença é significativa:

• 99,9% (três noves): ~8,7 horas de downtime por ano (~43 minutos por mês)
• 99,99% (quatro noves): ~52 minutos de downtime por ano (~4,3 minutos por mês)
• 99,999% (cinco noves): ~5,2 minutos de downtime por ano

Cada “nove” adicional requer um investimento exponencialmente maior em redundância, monitoramento e automação. A maioria das aplicações não precisa de mais do que três noves.

Resposta: C

O padrão recomendado é:

1. O API Gateway valida o token de autenticação (JWT, session, etc.)
2. Se for válido, propaga a identidade do usuário (userId, roles) para os serviços internos via headers
3. Os serviços internos confiam na identidade propagada e aplicam autorização de acordo com suas regras de negócio

Validar em cada serviço é redundante e custoso. Validar apenas no frontend é inseguro — o backend deve sempre verificar.