KF Cadernos interativos
ArquiteturaGitHub
Arquitetura de Software
Revisão P1

Mapa final: o que ligar na cabeça antes da prova

NecessidadeRF + RNF mensurável
DecisãoAlternativa + custo
EvidênciaCenário + teste
ComunicaçãoVisão + representação
Frase-molde: “Escolhi X para atender Y; aceito Z e verifico com W.”

Se a pergunta fala “módulos/dependências”

Pense em visão de desenvolvimento no 4+1.

Se fala “paralelo/mensagens/runtime”

Pense em visão de processos.

Se fala “portal/API/banco”

Pense em C4 Contêineres.

Se fala “usuários + sistemas externos”

Pense em C4 Contexto.

Exercício de revisão enviado

Parte I — marque a opção correta

Q1. Biblioteca quer app móvel sem duplicar regras de empréstimo já usadas no portal web. Qual decisão favorece evolução?

Q2. Qual RNF tem condições suficientes para orientar teste de desempenho?

Q3. Equipe pequena compara monólito modular e microserviços. Qual atuação é mais coerente com o papel do arquiteto?

Q4. No modelo 4+1, qual visão atende diretamente à preocupação “quais módulos do código podem depender de outros módulos”?

Q5. Um desenho mostra portal web, API e banco, com responsabilidades e comunicações. Qual nível C4?

Q6. API monolítica bate limite de CPU; banco ainda tem capacidade; requisições são stateless. Qual alternativa caracteriza escala horizontal?

Q7. Diagrama FitCampus mostra aplicativo móvel, API e banco como unidades com responsabilidades. Qual interpretação C4?

Parte II — revisão enviada

Q8 — Verdadeiro ou Falso

No MVC, o Model pode representar regras e estado do domínio, além do acesso a dados.
Três camadas lógicas exigem, obrigatoriamente, três servidores físicos.
Um contêiner do modelo C4 só pode ser representado se a aplicação usar Docker.
Um cenário de uso pode ajudar a verificar a coerência entre as quatro visões do modelo 4+1.
Criar uma réplica do banco elimina a necessidade de backup e de testes de restauração.
Uma fila pode absorver picos de trabalho, mas exige acompanhar atrasos e tratar reprocessamentos.
Gabarito comentado

V, F, F, V, F, V. A pegadinha principal é separar estrutura lógica de implantação física, lembrar que C4 não depende de Docker e que redundância não substitui backup.

Parte III — Q9

Biblioteca: API no limite de CPU + e-mail bloqueando resposta

Cenário: equipe de 4 pessoas, orçamento limitado, API atinge CPU máxima, banco ainda tem capacidade e e-mail externo demora 6 s e bloqueia a confirmação do empréstimo. A equipe considera manter monólito modular ou separar domínio em microserviços.

a) RF + RNF mensurável de desempenho

RF: registrar empréstimo e confirmar ao aluno. RNF: sob 100 req/s por 10 min, 95% das confirmações devem retornar em até 2 s, sem depender do tempo de resposta do provedor de e-mail.

b) Monólito modular ou microserviços?

Para equipe pequena e orçamento limitado, monólito modular é uma escolha defensável se as fronteiras forem claras e a pressão principal for CPU da API + e-mail síncrono. Benefício: menor custo operacional e transacional. Contrapartida: menor autonomia de deploy/escala por capacidade. Microserviços podem fazer sentido depois se surgirem drivers concretos de independência.

c) Uma medida para saturação da API e outra para e-mail

API: múltiplas instâncias stateless atrás de balanceador; escalar horizontalmente após teste de carga. E-mail: persistir empréstimo e publicar tarefa em fila/outbox; worker envia assíncrono. A confirmação não espera e-mail.

d) Como testar escala e falha do e-mail?

Escala: carga progressiva e em pico, medir throughput, CPU e p95/p99 antes/depois de adicionar instância. E-mail: simular timeout/erro, verificar que empréstimo confirma, pendência fica registrada, retry não duplica efeito e envio é retomado quando serviço volta.

Parte III — Q10

Biblioteca: portal, API, banco, e-mail e duas instâncias da API

a) Nível C4 para explicar ao negócio quem usa e quais sistemas externos participam

Contexto. Deve mostrar pelo menos pessoas/atores do negócio, sistema Biblioteca e provedor externo de e-mail. O objetivo é fronteira e relações externas, não banco ou instâncias.

b) Nível C4 para portal, API e banco; e como representar duas APIs

Contêineres. Portal web, API e banco são unidades executáveis/armazenamento. As duas APIs são duas instâncias de implantação do mesmo contêiner lógico; isso pode ser detalhado em diagrama de implantação, não como dois contêineres conceitualmente diferentes.

c) Visão 4+1 para mensagens e concorrência em execução

Visão de Processos. Uma sequência/interação em runtime é adequada: Portal → API → Banco → Fila/Worker → E-mail, destacando assíncrono e concorrência.

d) Cenário +1 conectando as quatro visões

Cenário “realizar empréstimo”: Lógica mostra Empréstimo/Usuário/Livro e regras; Desenvolvimento mostra módulos/contratos; Processos mostra chamada, persistência e notificação assíncrona; Física mostra API replicada, banco e worker; o +1 verifica que os nomes e responsabilidades permanecem coerentes ao atravessar tudo.

Questões enviadas em foto

Questões rápidas de qualidade, disponibilidade e resiliência

Por que um atributo de qualidade deve possuir medida objetiva de resposta?

Porque requisitos vagos não orientam projeto nem validação. A medida permite verificar se o requisito foi atendido e comparar alternativas. Ex.: “p95 < 500 ms com 5.000 usuários simultâneos”.

Qual diferença correta entre disponibilidade e escalabilidade?

Disponibilidade trata de o sistema estar acessível quando necessário; escalabilidade trata de crescer capacidade com aumento de demanda sem perder qualidade de forma inaceitável. Um sistema pode precisar de uma sem exigir fortemente a outra.

Sistema 24×7 com apenas 35 usuários pode ignorar redundância?

Não. Poucos usuários reduzem pressão de escala, mas não mudam a criticidade de disponibilidade. Se a indisponibilidade afeta a operação, ainda é preciso tratar falhas, recuperação e pontos únicos.

Aplicativo de coleta deve armazenar localmente e enviar quando a conexão retornar. É coerente?

Sim. É uma estratégia offline-first coerente, desde que inclua persistência durável, fila de pendências, retries, idempotência e política de conflito.

API externa falha intermitentemente. Retry controlado + circuit breaker contribui para resiliência?

Sim. Retry pode absorver falhas transitórias; circuit breaker evita insistência quando a dependência está degradada e reduz propagação de falha. É preciso limitar tentativas e observar estado.

Discursiva enviada em foto

Estratégia arquitetural para operação offline e posterior sincronização

DispositivoBanco local transacional, UUID, estado de sync, versão/timestamp, anexos referenciados, proteção de dados locais.
SincronizaçãoFila local, worker em background, lotes, confirmação por item, backoff e retomada.
DuplicidadeIdempotency key/UUID compartilhado com servidor.
ConflitoVersionamento otimista; regra explícita de merge ou resolução assistida.
FalhasNão apagar pendência antes de ACK; reprocessar com limite; expor status ao usuário.
AtributosDisponibilidade, integridade, confiabilidade, desempenho, segurança e usabilidade.
Resposta em 4 linhas para prova: “Persisto cada coleta localmente com UUID e estado de sincronização. Quando a rede voltar, um worker envia pendências com retry/backoff e confirmação por item. O servidor usa idempotência para impedir duplicatas e versionamento para detectar conflitos. A solução prioriza disponibilidade offline e integridade/confiabilidade, aceitando maior complexidade de consistência.”
Checklist final

Modelo de resposta discursiva que cabe em praticamente qualquer cenário

  1. Nomeie o driver: “O principal atributo aqui é disponibilidade / desempenho / escalabilidade / evolução...”
  2. Mostre a decisão: “Para atender isso, adotaria...”
  3. Explique o mecanismo: “A decisão funciona porque...”
  4. Diga o custo: “Em troca, aumenta...”
  5. Valide: “Testaria com...”
Evite: “microserviços porque escala”, “cloud porque é melhor”, “cache deixa rápido”, “redundância resolve tudo”. Sempre relacione decisão → requisito → custo → evidência.