Gestão de Riscos e Trade-offs em Arquitetura: Risk Storming e ADRs

Não existem soluções perfeitas em arquitetura de software: existem apenas trade-offs (compromissos de engenharia onde você ganha um benefício em troca de aceitar um custo ou risco correspondente). Ignorar essa realidade resulta na escolha de tecnologias baseada em moda de mercado, gerando desastres operacionais quando a fatura técnica da decisão chega em produção.

flowchart LR
  subgraph RiskStorming["Sessão de Risk Storming"]
    Diagrama["Diagrama C4 de Arquitetura"]
    Ameacas["Identificação Colaborativa de Riscos"]
    Matriz["Classificação na Matriz Probabilidade x Impacto"]
    Diagrama --> Ameacas --> Matriz
  end

  subgraph Mitigacao["Registro e Mitigação"]
    Acao["Ação de Arquitetura (Spike / Prova de Conceito)"]
    ADR["ADR Formal (Architecture Decision Record)<br/>Registra o Trade-off e Consequências"]
    Matriz --> Acao --> ADR
  end

A Dinâmica do Risk Storming

Criado como parte da metodologia do Modelo C4 por Simon Brown, o Risk Storming é uma dinâmica visual e colaborativa onde arquitetos, desenvolvedores e especialistas em segurança examinam um diagrama de arquitetura procurando vulnerabilidades e falhas potenciais antes do início do código:

1. Imprime-se ou projeta-se o diagrama de containers e componentes do sistema.
2. Cada participante cola notas adesivas coloridas sobre os nós e conexões que representam riscos (segurança, escalabilidade, dependência de terceiros, integridade de dados).
3. A equipe pontua a severidade de cada risco na matriz de Probabilidade versus Impacto.
4. Definem-se planos de contingência concretos para mitigar os pontos críticos.

Registrando Decisões com ADRs (Architecture Decision Records)

Quando uma decisão arquitetural relevante é tomada — como escolher entre Kafka ou Azure Service Bus, ou adotar PostgreSQL em vez de MongoDB —, essa decisão deve ser documentada em um arquivo Markdown simples versionado junto com o código do projeto:

# ADR 007: Adoção do PostgreSQL com Extensão pgvector para Busca Semântica

## Status
Aceito (2026-10-03)

## Contexto
Precisamos implementar busca vetorial para o assistente de IA interno. 
Avaliamos contratar uma instância dedicada do Pinecone versus habilitar a extensão pgvector 
em nossa instância existente de Azure Database for PostgreSQL.

## Decisão
Decidimos utilizar o Azure Database for PostgreSQL com pgvector.

## Consequências
### Positivas:
- Custo zero adicional de infraestrutura gerenciada.
- Possibilidade de executar consultas híbridas combinando filtros relacionais SQL (status, cliente) 
  e distância de cosseno na mesma query transacional ACID.
### Negativas (Trade-offs Aceitos):
- Índices HNSW consomem cerca de 30% mais memória RAM da instância existente.
- Limite prático de escala em torno de dezenas de milhões de vetores sem particionamento complexo.

Ao formalizar o contexto e as consequências de cada compromisso técnico, a organização evita discussões circulares recorrentes e protege as decisões arquiteturais contra a perda de memória institucional.