Architecture kata: exercícios práticos para treinar tomada de decisão

1. O que são Architecture Katas e por que praticá-los?

Architecture Katas são exercícios estruturados que simulam problemas reais de design de software, inspirados nos coding katas — práticas repetitivas para aperfeiçoar habilidades técnicas. Enquanto um coding kata treina a implementação de algoritmos, um architecture kata treina o raciocínio sobre trade-offs arquiteturais.

O objetivo central é desenvolver o "músculo" da tomada de decisão. Na teoria, estudamos padrões como microsserviços, CQRS ou event sourcing. Na prática, precisamos decidir quando e por que aplicá-los, considerando contexto, restrições de negócio e time. O kata força o arquiteto a justificar cada escolha com base em requisitos concretos, não em modismos.

A diferença crucial entre teoria e prática é que katas expõem o dilema real: não existe solução perfeita, apenas soluções adequadas a um conjunto de trade-offs.

2. Estrutura típica de um Architecture Kata

Um kata geralmente segue esta estrutura:

  • Cenário e requisitos funcionais: descrição do problema (ex.: "sistema de e-commerce com 10 mil produtos, 100 mil usuários ativos, vendas em 5 países").
  • Restrições arquiteturais: performance (< 200ms de resposta), escalabilidade (picos de Black Friday), custo (budget de infraestrutura), time-to-market (MVP em 3 meses).
  • Entregáveis esperados:
  • Diagrama de containers (C4)
  • Architecture Decision Records (ADRs)
  • Justificativas escritas para cada decisão

O formato é intencionalmente incompleto — cabe ao arquiteto fazer perguntas esclarecedoras sobre o domínio, como faria com um Product Owner real.

3. As dimensões críticas de decisão nos katas

Três dimensões aparecem repetidamente:

Estilo arquitetural

Monólito modular vs. microsserviços. A escolha depende do tamanho da equipe, da necessidade de deploy independente e da maturidade do domínio.

Comunicação entre componentes

Síncrona (REST/gRPC) vs. assíncrona (event-driven). A decisão impacta latência, resiliência e complexidade de debugging.

Persistência

Banco relacional, NoSQL, poliglota, CQRS. Cada abordagem resolve um problema diferente de consistência e performance.

4. Exemplo prático passo a passo: Sistema de e-commerce

Cenário: Marketplace com catálogo de produtos, carrinho de compras, processamento de pagamentos e notificações (email/SMS). Requisitos: suportar 10 mil transações/dia, escalar para 100 mil em picos, time de 8 pessoas.

Decisão 1: Separação em bounded contexts e saga

Identificamos quatro contextos delimitados: Catálogo, Carrinho, Pagamento, Notificação. O fluxo de compra envolve múltiplos contextos, exigindo uma saga para garantir consistência eventual.

Opção A — Saga coreografada: Cada contexto publica eventos e reage a eventos de outros. Exemplo de fluxo:

Evento: "PedidoCriado" (Carrinho -> Catálogo)
Evento: "EstoqueReservado" (Catálogo -> Pagamento)
Evento: "PagamentoAprovado" (Pagamento -> Notificação)

Opção B — Saga orquestrada: Um orquestrador central (ex.: serviço de Pedido) coordena as etapas.

Decidimos pela saga coreografada porque:
- Menor acoplamento entre times (cada time gerencia seu contexto)
- Menos pontos únicos de falha
- Melhor alinhamento com DDD e event sourcing

O catálogo tem alta taxa de leitura (95%) e baixa taxa de escrita (5%). Duas opções:

Opção A — Redis como cache de leitura: Dados quentes armazenados em cache, banco relacional como fonte da verdade.

Fluxo de leitura:
1. Cliente busca produto
2. API consulta Redis (cache)
3. Se cache miss, consulta PostgreSQL e popula Redis

Opção B — Materialized views no banco de leitura: Views pré-calculadas no PostgreSQL para consultas rápidas.

Escolhemos Redis porque:
- Menor latência (sub-milissegundo vs. 5-10ms no PostgreSQL)
- Facilidade de escalar horizontalmente
- Custo operacional baixo para 10 mil transações/dia

Decisão 3: Consistência para estoque vs. pagamento

  • Estoque: Consistência eventual é aceitável (dois usuários podem ver o mesmo item disponível, mas apenas um finaliza a compra). Usamos eventos assíncronos para atualizar o estoque.
  • Pagamento: Consistência forte é obrigatória. Usamos transações ACID no banco de pagamento e bloqueio otimista.
Exemplo de ADR para Pagamento:
Título: Consistência forte para processamento de pagamentos
Contexto: Pagamentos exigem atomicidade para evitar duplicidade
Decisão: Usar transações ACID com bloqueio otimista no banco PostgreSQL
Consequências: Menor throughput em picos, mas garantia de integridade financeira

5. Ferramentas e templates para documentar decisões

Architecture Decision Records (ADRs)

Um ADR documenta uma decisão arquitetural importante. Template mínimo:

Título: [Decisão específica]
Contexto: [Problema, restrições, alternativas consideradas]
Decisão: [Escolha final e justificativa]
Consequências: [Impactos positivos e negativos]

Diagramas C4

Use o modelo C4 para comunicação visual: Contexto (sistema geral), Container (serviços/microsserviços), Componente (módulos internos), Código (classes específicas). Ferramentas: Structurizr, PlantUML, Draw.io.

Matriz de trade-offs

Crie uma tabela comparativa para decisões complexas:

Alternativa Latência Complexidade operacional Custo Manutenibilidade
Cache Redis 1ms Baixa Médio Alta
Materialized View 5ms Média Baixo Média

6. Como avaliar e evoluir sua solução no kata

Critérios de avaliação

  • Atendimento a requisitos: A solução resolve o problema proposto?
  • Justificativa de trade-offs: As decisões são explicadas com base no contexto, não em preferências pessoais?
  • Clareza da documentação: ADRs e diagramas são compreensíveis para um novo membro do time?

Anti-padrões comuns

  • Superengenharia: Usar microsserviços para um sistema com 3 funcionalidades e time de 2 pessoas.
  • Ignorar restrições: Propor soluções cloud-native quando o cliente exige on-premises.
  • Decisões sem contexto: "Escolhi NoSQL porque é moderno" — sem mencionar padrões de acesso ou requisitos de escalabilidade.

Iteração

Após feedback, refatore a arquitetura. Exemplo: Se o time cresce de 8 para 30 pessoas, talvez a saga coreografada precise evoluir para orquestrada para facilitar governança.

7. Katas avançados: incorporando desafios reais

Cenário com legado: Migração de monólito para microsserviços

Problema: Monólito de 500 mil linhas, time de 40 pessoas, deploy semanal. Desafio: Identificar bounded contexts, planejar migração incremental (strangler fig pattern), decidir entre event-driven ou API Gateway.

Cenário com restrições de infra: Cloud vs. on-premises

Problema: Cliente regulado (LGPD/GDPR) exige dados on-premises, mas quer elasticidade de cloud para picos. Solução híbrida: Dados sensíveis on-premises, cache e computação em cloud.

Cenário com requisitos extremos: Latência < 10ms, disponibilidade 99.999%

Desafio: Sistema de trading financeiro. Decisões: usar gRPC em vez de REST, cache local em memória, replicação síncrona entre data centers, circuit breakers em todos os pontos.

8. Próximos passos: como integrar katas no aprendizado contínuo

Katas públicos recomendados

  • Neal Ford's Architecture Katas (O'Reilly): Conjunto clássico com cenários variados.
  • ThoughtWorks Technology Radar: Casos reais de clientes.
  • KataCatalogue (GitHub): Repositório comunitário com dezenas de cenários.

Como organizar sessões em equipe

  • Timebox: 2 horas para um kata completo (30 min para entender o cenário, 60 min para design, 30 min para apresentação e feedback).
  • Role-playing: Atribua papéis (Product Owner, Arquiteto, Desenvolvedor, Cliente) para simular discussões reais.
  • Retrospectiva: Ao final, discuta o que funcionou e o que poderia ser melhorado no processo.

Conexão com o projeto final

Os katas fornecem o vocabulário e a prática necessários para aplicar architecture decision records, diagramas C4 e análise de trade-offs em projetos reais. No próximo artigo, usaremos esses aprendizados para projetar um sistema de saúde com requisitos de compliance e alta disponibilidade.

Referências