1.1 Uma definição que serve

Há dezenas de definições acadêmicas. A mais prática, atribuída a Ralph Johnson e popularizada por Martin Fowler: "arquitetura é o conjunto de decisões que você gostaria de ter acertado cedo — as coisas que são difíceis e caras de mudar depois". Onde ficam as fronteiras entre módulos, se há um ou vinte bancos de dados, se a comunicação é síncrona ou por eventos, qual a estratégia de consistência — mudar qualquer uma dessas em um sistema grande custa meses.

1.2 Atributos de qualidade (os "-ilities")

Requisitos funcionais dizem o que o sistema faz. Atributos de qualidade dizem quão bem — e é o que a arquitetura serve. Os principais:

1.3 Tudo é trade-off

A frase mais importante da apostila: "depende" é a resposta profissional. Não existe arquitetura "melhor" — existe a mais adequada às forças do seu contexto. Microservices compram escalabilidade e autonomia de time ao custo de complexidade operacional, latência de rede e consistência distribuída. Cache compra latência ao custo de invalidação e possível dado velho. Consistência forte compra correção ao custo de disponibilidade sob partição (ver apostila de NoSQL, teorema CAP).

1.4 O papel de quem faz arquitetura

• Identificar os atributos de qualidade que importam para este sistema e negociá-los com o negócio (não dá para maximizar todos).
• Decidir a estrutura e as fronteiras, e documentar o porquê (ADRs — Módulo 9).
• Manter a integridade conceitual: o sistema deve parecer projetado por uma mente só, mesmo feito por muitas.
• Reduzir risco cedo: provar as decisões arriscadas com spikes/protótipos antes de comprometer o time.
• Continuar codando o suficiente para não perder contato com a realidade ("arquiteto de PowerPoint" não funciona).

2.1 Acoplamento e coesão

• Coesão (alta é bom): o quanto os elementos dentro de um módulo pertencem juntos. Um módulo coeso tem uma responsabilidade clara; muda por um motivo só.
• Acoplamento (baixo é bom): o quanto um módulo depende de outro. Baixo acoplamento = mudar A raramente obriga a mudar B.

Praticamente toda "boa arquitetura" é uma forma de buscar alta coesão dentro das fronteiras e baixo acoplamento entre elas. Tipos de acoplamento, do pior ao mais tolerável: de conteúdo (mexe nas entranhas do outro) → comum (estado global compartilhado) → de controle (passa flag que dita o comportamento) → de dados (troca só os dados necessários por uma interface).

2.2 Fronteiras e inversão de dependência

Uma fronteira é uma linha através da qual as dependências apontam em uma direção controlada. O princípio de inversão de dependência (o "D" de SOLID): módulos de alto nível (regra de negócio) não devem depender de módulos de baixo nível (banco, framework, API externa); ambos dependem de abstrações.

   SEM inversão:  [regra de negócio] ──depende──▶ [Postgres] [Stripe] [SendGrid]
                  (trocar de banco = reescrever a regra)

   COM inversão:  [regra de negócio] ──▶ [interface Repositório] ◀──implementa── [Postgres]
                  [regra de negócio] ──▶ [interface Pagamentos]  ◀──implementa── [Stripe]
                  (a regra não conhece a tecnologia; adapters são plugáveis e testáveis)

É a base de arquitetura hexagonal / ports & adapters / clean architecture (Módulo 3): o núcleo de domínio no centro, sem dependência de infraestrutura; tudo que é I/O é um adaptador na borda.

2.3 Lei de Conway

"Organizações projetam sistemas que copiam a estrutura de comunicação da própria organização." (Melvin Conway, 1967.) Consequências práticas:

• Se você tem 4 times, vai acabar com ~4 componentes com interfaces onde os times se falam — queira você ou não.
• Inverse Conway Maneuver: organize os times do jeito que você quer que a arquitetura fique. Times autônomos por domínio de negócio ⇒ serviços autônomos por domínio.
• Uma fronteira arquitetural que corta no meio de um time gera atrito permanente; alinhe fronteiras de código com fronteiras de time.

2.4 Complexidade essencial × acidental

De "No Silver Bullet" (Fred Brooks): a complexidade essencial é a do problema em si (um sistema de logística é complexo). A acidental é a que você adiciona com ferramentas, camadas e abstrações mal escolhidas. Bom arquiteto ataca a acidental sem fingir que elimina a essencial. Toda camada, todo serviço, toda tecnologia nova é complexidade acidental que precisa se pagar.

3.1 Monólito (e o monólito modular)

Uma única unidade de deploy. Não é sinônimo de bagunça: um monólito modular tem fronteiras internas explícitas (módulos com interfaces claras, sem acesso ao banco um do outro), roda como um processo, e é a escolha certa para a esmagadora maioria dos sistemas no início e por muito tempo.

• Ganha: simplicidade operacional (um deploy, um banco, um repositório), transações locais (ACID de graça), refatoração fácil entre módulos, latência mínima, observabilidade trivial.
• Custa: escala como um bloco só; um bug de memória derruba tudo; deploy acopla os times; acima de certo tamanho, o build e o onboarding pesam.

3.2 Camadas (layered / n-tier)

Organização horizontal: apresentação → aplicação → domínio → persistência. Familiar e fácil de ensinar. Risco: virar um "monólito em camadas" onde toda feature atravessa todas as camadas e a de domínio depende da de persistência (acoplamento invertido). Combine com inversão de dependência.

3.3 Hexagonal / Ports & Adapters / Clean

Organização concêntrica: domínio puro no centro; "portas" (interfaces) ao redor; "adaptadores" (HTTP, banco, filas, APIs externas) na borda, dependendo para dentro. Ótimo para testabilidade (o domínio roda sem infraestrutura) e para trocar tecnologia sem tocar a regra. É um padrão interno — combina com monólito modular ou com cada microserviço.

3.4 Microservices

Vários serviços pequenos, cada um com seu deploy, seu time e (idealmente) seu banco, comunicando-se por rede.

3.5 Event-Driven Architecture (EDA)

Componentes reagem a eventos (fatos que aconteceram: PedidoPago, UsuárioCadastrado) publicados num broker (Kafka, RabbitMQ, SNS/SQS). O produtor não sabe (nem espera) quem consome.

• Ganha: desacoplamento forte (adicionar consumidor sem tocar o produtor), resiliência (o broker absorve picos e quedas), extensibilidade, auditoria natural (o log de eventos).
• Custa: fluxo difícil de seguir ("onde isso é tratado?"), consistência eventual, necessidade de idempotência e de lidar com ordem/duplicação, testes e debugging mais complexos.
• Sabores: notificação de evento (evento fino, consumidor busca o resto), event-carried state transfer (evento gordo, carrega os dados), event sourcing (o evento é a fonte de verdade — Módulo 5).

3.6 Serverless (FaaS)

Funções que sobem sob demanda, escalam a zero, você paga por invocação. Ótimo para cargas intermitentes, glue code, processamento orientado a evento, e times que não querem gerir servidor. Custa: cold start, limites de execução, lock-in, e custo alto em volume constante. Frequentemente combinado com EDA.

3.7 Um guia rápido de escolha

4.1 Síncrono × assíncrono

4.2 REST × gRPC × GraphQL (resumo)

• REST/JSON: universal, cacheável, ótimo para APIs públicas e entre times heterogêneos.
• gRPC: binário (Protobuf), contrato forte, streaming, baixa latência — ótimo entre serviços internos de alta comunicação.
• GraphQL: o cliente pede exatamente os campos que quer; bom para agregar dados de várias fontes para front-ends variados; cuidado com N+1 e com cache. (Ver a apostila de API Design para o detalhe.)

4.3 Coordenação: orquestração × coreografia

Quando um processo de negócio cruza vários serviços (ex.: "fazer um pedido" toca estoque, pagamento, entrega):

Regra prática: processos de negócio complexos e com muitas regras de compensação ⇒ orquestração (com um motor de workflow tipo Temporal/Camunda se justificar). Propagação de fatos simples ⇒ coreografia.

4.4 Padrões de borda

• API Gateway: ponto único de entrada — roteamento, autenticação, rate limiting, agregação, TLS. Evita que cada cliente conheça a topologia interna.
• Backend for Frontend (BFF): um gateway/serviço por tipo de cliente (web, mobile, parceiro), que agrega e molda os dados sob medida — em vez de uma API genérica que serve mal a todos.
• Service Mesh (Istio, Linkerd): move retries, mTLS, observabilidade e roteamento para uma camada de infraestrutura (sidecar). Poderoso e complexo — só quando a quantidade de serviços justifica.

5.1 Database per service e o fim do JOIN

Em microservices, cada serviço é dono do seu banco e ninguém mais o acessa direto (senão o acoplamento volta pela porta dos fundos). Consequências: acabou o JOIN entre domínios, acabou a transação ACID que abrange dois serviços, e "montar uma tela com dados de 4 serviços" vira um problema de arquitetura.

5.2 O problema do dual-write

"Vou gravar no meu banco e publicar o evento no Kafka." Se a segunda operação falha (ou o processo morre entre as duas), os sistemas divergem — e não há transação entre banco e broker.

5.3 Saga — transações que cruzam serviços

Uma saga é uma sequência de transações locais, cada uma num serviço, com uma transação de compensação para desfazer cada passo se um posterior falhar (não há rollback distribuído).

Pedido:  reservar estoque ──▶ cobrar pagamento ──▶ agendar entrega
                                     │ falhou!
                                     ▼
compensação:  estornar pagamento ◀── liberar estoque   (desfaz na ordem inversa)

• Saga coreografada: cada serviço reage a eventos e emite o próximo (ou o de compensação). Simples para poucos passos; vira sopa de eventos se crescer.
• Saga orquestrada: um orquestrador conduz os passos e as compensações. Melhor para fluxos com muitas regras; um motor de workflow ajuda.
• Exige pensar em semântica de compensação (nem tudo é reversível — e-mail enviado não "desenvia"; use compensação semântica: mandar um e-mail de correção).

5.4 CQRS

Command Query Responsibility Segregation: separar o modelo de escrita (comandos, normalizado, com regras de negócio) do modelo de leitura (queries, desnormalizado, otimizado para as telas). O modelo de leitura é atualizado a partir de eventos do modelo de escrita.

• Ganha: leitura e escrita escalam e evoluem separadas; telas complexas viram consultas triviais em um modelo feito sob medida; junta dados de vários serviços num read model.
• Custa: dois modelos para manter; consistência eventual entre eles (a leitura pode estar alguns ms atrás); mais infraestrutura.
• Não precisa de event sourcing — são independentes, embora combinem bem.

5.5 Event Sourcing avançado

Em vez de guardar o estado atual, guarde a sequência de eventos que levou a ele (ContaAberta, Depositado 100, Sacado 30 ⇒ saldo 70). O estado é uma projeção (fold) dos eventos.

• Ganha: auditoria perfeita, "viagem no tempo", capacidade de reconstruir novas projeções do zero, debugging por replay.
• Custa: complexidade alta, versionamento de eventos (o schema evolui e os eventos antigos são imutáveis), consultas exigem projeções, curva de aprendizado do time. Use com parcimônia, em domínios onde auditoria/histórico é requisito central (financeiro, jurídico).

5.6 Consistência eventual e idempotência

• Consistência eventual: em sistemas distribuídos, aceita-se que réplicas/projeções converjam "em breve", não instantaneamente. Projete a UX para isso (mostrar "processando", ler o próprio write localmente, evitar prometer o que ainda não confirmou).
• Idempotência: como a entrega é at-least-once, todo consumidor precisa processar a mesma mensagem duas vezes com o mesmo efeito de uma. Técnicas: chave de idempotência + tabela de "já processados"; upsert por id; operações naturalmente idempotentes.
• Ordem: não conte com ordem global. Use chave de particionamento para ordem por entidade, ou torne o processamento insensível à ordem.

6.1 Vertical × horizontal

• Escala vertical: máquina maior. Simples, limitado por um teto físico e por preço exponencial; não ajuda em disponibilidade.
• Escala horizontal: mais máquinas. Sem teto prático, melhora disponibilidade, mas exige que o serviço seja stateless (nenhum estado de sessão na memória do processo) para qualquer instância atender qualquer requisição.

Tornar stateless: sessão em cookie assinado ou em store compartilhado (Redis); uploads e arquivos em object storage; nada de "afinidade de sessão" como muleta permanente.

6.2 Balanceamento de carga

• L4 (transporte) vs L7 (aplicação): L7 entende HTTP, roteia por path/header, faz TLS termination, health checks.
• Algoritmos: round-robin, least-connections, hash consistente (para afinidade de cache/estado), weighted.
• Health checks ativos removem instâncias doentes; graceful shutdown drena conexões antes de matar o processo no deploy.

6.3 Caching — a maior alavanca de performance

• Padrões: cache-aside (a app consulta o cache, no miss busca a fonte e popula), read-through/write-through, write-behind.
• Invalidação — "a segunda coisa mais difícil da computação": TTL (simples, aceita dado velho por um tempo), invalidação por evento (preciso, mais complexo), versionar a chave.
• Armadilhas: cache stampede (muitas chaves expiram juntas e todo mundo vai à fonte — mitigar com TTL + jitter e lock de recomputação), hot key, e cachear dado por usuário sem necessidade.

6.4 Particionamento e sharding

• Replicação (cópias do mesmo dado) escala leitura e dá disponibilidade; particionamento/sharding (fatias diferentes em nós diferentes) escala escrita e armazenamento.
• Shard key é a decisão crítica: alta cardinalidade, distribuição uniforme, e presente nas consultas frequentes. Chave ruim ⇒ hot shard ou toda query vira scatter-gather.
• Hash (distribui bem, mata range queries) vs range (bom para faixas, risco de hotspot) vs geográfico/tenant.
• Resharding é caro — planeje com folga (hash consistente, mais partições lógicas que físicas). Ver apostila de NoSQL para o detalhe.

6.5 Controle de fluxo: filas, back-pressure e limites

• Filas nivelam picos (load leveling): o produtor despeja rápido, o consumidor processa no seu ritmo.
• Back-pressure: quando o consumidor não dá conta, sinalizar para o produtor desacelerar (em vez de estourar memória). Bounded queues, rejeição explícita, load shedding (descartar o excedente de forma controlada).
• Rate limiting (token bucket, sliding window) protege o serviço de abuso e de vizinho barulhento.
• Noção de teoria de filas: conforme a utilização se aproxima de 100%, a latência de espera dispara (não é linear). Sistemas saudáveis operam com folga (~60–70% de utilização), não no talo.

7.1 A premissa: tudo falha

Discos morrem, redes particionam, dependências ficam lentas, deploys quebram, uma zona de disponibilidade cai. Arquitetura resiliente não tenta impedir toda falha — ela contém o raio de explosão e degrada com elegância em vez de cair por inteiro.

7.2 Elimine pontos únicos de falha (SPOF)

• Redundância em toda camada: múltiplas instâncias, múltiplas zonas de disponibilidade, réplicas de banco com failover.
• Cuidado com SPOFs escondidos: um único balanceador, um único NAT gateway, um serviço de config que todo mundo consulta na inicialização, o DNS, um segredo que só uma pessoa tem.
• Disponibilidade compõe: componentes em série multiplicam (pioram); redundância em paralelo aproxima de 100%.

7.3 Os padrões de tolerância a falha

7.4 Recuperação de desastre

• RTO (Recovery Time Objective): quanto tempo até voltar. RPO (Recovery Point Objective): quanto dado você aceita perder (janela desde o último backup replicado).
• Estratégias por custo/agressividade: backup & restore → pilot light → warm standby → multi-site ativo-ativo.
• Backup que nunca foi restaurado não é backup. Teste a restauração periodicamente.
• Runbooks e automação para os cenários prováveis; game days e engenharia do caos (derrubar coisas de propósito) para validar que a resiliência projetada funciona de verdade.

8.1 O que o entrevistador avalia

Não é a "resposta certa" (não existe). É: você esclarece requisitos antes de desenhar? Estrutura o raciocínio ou pula direto para a solução? Justifica escolhas com trade-offs? Conhece os números (o que cabe em RAM, latência de disco vs rede, QPS por máquina)? Identifica gargalos e sabe aprofundar quando pedem? Comunica com clareza?

8.2 O framework (≈45 min)

8.3 Números que você precisa ter na cabeça

Latências de referência (ordem de grandeza):
  ler 1 MB da memória ........... ~0,25 ms
  SSD: leitura aleatória ........ ~0,1 ms
  round-trip na mesma região .... ~0,5 ms
  round-trip entre continentes .. ~150 ms

Capacidade (folgada, "de guardanapo"):
  QPS por instância de app ...... ~1.000 (varia MUITO com a carga)
  linhas que cabem em RAM ....... milhões a dezenas de milhões
  1 dia = 86.400 s  →  1M eventos/dia ≈ ~12/s médio  (pico pode ser 5–20× a média)

Regra do 80/20 e leitura-pesada:
  a maioria dos sistemas de produto é 10:1 a 1000:1 leitura:escrita → cache e réplicas mandam

8.4 Padrões que reaparecem

• URL shortener / pastebin: geração de id (hash vs contador vs base62), KV store, cache, redirecionamento 301/302, analytics assíncrono.
• Feed / timeline: fan-out on write (empurra para o feed de cada seguidor — bom para quem tem poucos seguidores) vs fan-out on read (monta na hora — bom para celebridades); híbrido é a resposta.
• Chat / mensageria: conexões persistentes (WebSocket), presença, entrega e ordenação por conversa, armazenamento em wide-column, notificações push.
• Rate limiter: token bucket em Redis, sliding window, distribuído com alguma folga de precisão.
• Sistema de notificações: filas por canal, retry, deduplicação, preferências do usuário, provedores externos com fallback.
• Busca / typeahead: índice invertido (Elasticsearch), trie para autocomplete, sincronização via CDC.

9.1 Documentar decisões: ADRs

Um Architecture Decision Record é um arquivo curto (uma página) no repositório, versionado com o código, que registra uma decisão: contexto, opções consideradas, decisão tomada, consequências (boas e ruins), e status (proposto/aceito/substituído). O valor não é o documento — é forçar o raciocínio e deixar rastro para quem chegar depois perguntar "por que isto é assim?".

# ADR-014: Usar outbox para publicação de eventos de domínio

## Status: Aceito (2026-03)
## Contexto
Precisamos publicar eventos quando um pedido muda de estado. Dual-write
(gravar no banco + publicar no broker) pode divergir em falha parcial.
## Decisão
Inserir o evento numa tabela `outbox` na mesma transação do banco; um relay
CDC publica no broker.
## Consequências
+ Sem perda/divergência de evento; entrega at-least-once.
+ Consumidores DEVEM ser idempotentes (aceito).
- Uma peça a mais (o relay) para operar e monitorar.

9.2 Comunicar a estrutura: o modelo C4

Quatro níveis de zoom, cada um um diagrama simples: Contexto (o sistema e quem interage com ele) → Contêineres (apps, serviços, bancos — as unidades de deploy) → Componentes (dentro de um contêiner) → Código (raramente necessário). Substitui o diagrama "UML gigante que ninguém entende" por uma hierarquia legível. Poucas caixas, legendas claras, uma história por diagrama.

9.3 Arquitetura evolutiva e fitness functions

• Premissa: a arquitetura vai mudar; projete para a mudança guiada, não para a perfeição inicial.
• Fitness function: um teste automatizado que verifica um atributo arquitetural — "nenhum módulo de domínio importa o pacote de infraestrutura" (ArchUnit), "o p99 do endpoint X fica abaixo de 200 ms" (teste de performance no CI), "nenhum serviço acessa o banco de outro". Torna as regras arquiteturais executáveis em vez de wiki que ninguém lê.

9.4 Avaliar uma arquitetura

ATAM (Architecture Tradeoff Analysis Method) é o método formal: a partir de cenários de atributos de qualidade ("o tráfego dobra na Black Friday", "um data center cai", "adicionamos um novo tipo de pagamento"), avalia-se como a arquitetura responde, quais os pontos de sensibilidade e os trade-offs. Mesmo informalmente, "rodar cenários" é a melhor forma de estressar um desenho antes de construí-lo.

9.5 Anti-padrões

9.6 Migração incremental: Strangler Fig

Nunca faça o "big bang rewrite". O padrão strangler fig (Fowler): coloque uma fachada (proxy/gateway) na frente do sistema legado; construa cada capacidade nova (ou reescrita) atrás dela; roteie o tráfego daquela função para o novo componente; repita até o legado "estrangulado" poder ser desligado. Combine com shadow traffic (o novo processa em paralelo sem servir) e feature flags para reduzir risco.

10.1 Onde arquitetura pesa na carreira

10.2 Roadmap de estudo (8–10 semanas)

10.3 Banco de perguntas de entrevista (com a resposta que aprova)

10.4 Como demonstrar competência de arquitetura

1. Documentar um sistema real (seu, de trabalho anonimizado, ou open source) com diagramas C4 e uma série de ADRs explicando as decisões e os trade-offs. Publicar.
2. Estudo de system design escrito: escolher um produto conhecido, aplicar o framework do Módulo 8 num artigo, com estimativas e alternativas.
3. Projeto que mostra um padrão distribuído: uma saga com compensação, ou CQRS com read model alimentado por eventos, ou um serviço com circuit breaker + outbox — pequeno, mas correto e explicado.
4. Refatoração documentada: pegar um projeto acoplado e mostrar o "antes/depois" ao introduzir fronteiras e inversão de dependência, com fitness functions garantindo as regras.
5. Contribuir em discussões de design (RFCs) de projetos open source.

10.5 Leituras de referência

• Fundamentos: Fundamentals of Software Architecture (Richards & Ford); Software Architecture: The Hard Parts (mesmos autores) para trade-offs de sistemas distribuídos.
• Dados distribuídos: Designing Data-Intensive Applications (Martin Kleppmann) — o livro definitivo, base dos Módulos 5–7.
• Microservices: Building Microservices (Sam Newman); Monolith to Microservices (mesmo autor) para o strangler.
• Padrões: Enterprise Integration Patterns (Hohpe & Woolf); o catálogo microservices.io (Chris Richardson) para saga/outbox/CQRS.
• Evolução: Building Evolutionary Architectures (Ford, Parsons, Kua); Team Topologies (Skelton & Pais) para a Lei de Conway na prática.
• Entrevista: System Design Interview (Alex Xu, vol. 1 e 2); o "System Design Primer" no GitHub.