Trilha 2

🧭 Estratégias de Decisão

Frameworks, trade-offs e métodos para tomar decisões arquiteturais com confiança

5
Módulos
35
Tópicos
~3h
de conteúdo
Inter.
Intermediário

Navegação Rápida

Módulo 2.1
Framework de Decisão Arquitetural
Como escolher a arquitetura certa para cada contexto
Módulo 2.2
Análise de Trade-offs
Toda decisão é uma troca — aprenda a fazer as certas
Módulo 2.3
Escolhendo a Stack Certa
Tecnologia é meio, não fim — como escolher sem cair no hype
Módulo 2.4
ADRs e Documentação de Decisão
Architecture Decision Records — a memória do projeto
Módulo 2.5
Migração e Evolução
Sistemas vivos mudam — aprenda a evoluir sem quebrar

Conteúdo Detalhado

Módulo 2.1 ~35 min

🧭 Framework de Decisão Arquitetural

Como escolher a arquitetura certa para cada contexto

O que é: Antes de escolher tecnologia, identifique o custo dominante do seu projeto. É a pergunta que antecede qualquer decisão: onde está o maior risco?
Por que aprender: Times que pulam essa pergunta escolhem stack por hype. Ex: Uma startup de 3 pessoas que escolhe Kubernetes "para escalar" gasta 60% do tempo em infra e 40% em produto — e fecha antes de precisar escalar.
Conceitos-chave: 4 riscos dominantes (velocidade, crescimento, organização, imprevisibilidade), Matriz de decisão, Fit-for-purpose
O que é: Quando o produto não está validado, a arquitetura deve maximizar velocidade de iteração. Monolito simples, deploy rápido, feedback loop curto.
Por que aprender: Gastar 3 meses em arquitetura para um produto que ninguém quer é desperdício. Ex: O Dropbox começou como um vídeo de demonstração — validou demanda antes de escrever uma linha de código. MVP real.
Conceitos-chave: Script → Monolito → Modular, Time-to-feedback, Throwaway prototypes, "Do things that don't scale"
O que é: Quando o produto tem tração e o time cresce, a arquitetura deve permitir evolução sem reescritas. Monolito modular com fronteiras claras.
Por que aprender: É o momento mais perigoso — pressão para adicionar features sem degradar qualidade. Ex: O Slack cresceu de 0 a 8M DAUs em 2 anos. Usaram monolito modular PHP → migraram gradualmente para serviços Go onde fazia sentido.
Conceitos-chave: Monolito modular, Feature flags, Strangler fig pattern, Database boundaries, API versioning
O que é: Quando múltiplos times precisam de deploys independentes sem coordenação. Aqui microsserviços fazem sentido — não pela tecnologia, mas pela organização.
Por que aprender: Microsserviços sem autonomia de times são overhead puro. Ex: A Amazon introduziu "two-pizza teams" (6-10 pessoas) antes de introduzir microsserviços. A estrutura organizacional veio primeiro, a tecnologia seguiu.
Conceitos-chave: Conway's Law, Team Topologies, Platform teams, API contracts, Ownership de serviço
O que é: Workloads com picos imprevisíveis (webhooks, viralizações, black friday). Serverless e event-driven absorvem a variação.
Por que aprender: Provisionar para o pico é caro; não provisionar é catastrófico. Ex: O iFood usa autoscaling agressivo — na final da Copa do Mundo, pedidos triplicam em 15 minutos. Serverless + queues absorvem sem intervenção.
Conceitos-chave: Serverless, EDA, Autoscaling, Queue-based load leveling, Burst capacity
O que é: Quando LLMs ou modelos de ML estão no fluxo crítico. Outputs variáveis, latências imprevisíveis, custos por token. Arquitetura precisa de guardrails.
Por que aprender: IA sem controle é uma bomba-relógio. Ex: O Bing Chat da Microsoft teve respostas alucinantes nas primeiras semanas — faltaram guardrails de output. Agora usa classificadores de segurança em cascade antes de cada resposta.
Conceitos-chave: Prompt engineering como infraestrutura, Output validation, Fallback chains, Cost control, Human-in-the-loop
O que é: Projetos reais combinam riscos. Um e-commerce tem velocidade (MVP) + imprevisibilidade (Black Friday) + organização (time crescendo). A arte é priorizar.
Por que aprender: Arquitetos inexperientes otimizam para um risco e ignoram os outros. Ex: A INEMA combina velocidade (novas features semanais) + IA (Claude Code no fluxo) + escala (comunidade crescente). Solução: monolito modular + n8n para automações + guardrails de IA.
Conceitos-chave: Risk matrix, Weighted scoring, Phased architecture, Architecture fitness functions
Ver Completo
Módulo 2.2 ~35 min

📊 Análise de Trade-offs

Toda decisão é uma troca — aprenda a fazer as certas

O que é: Toda decisão arquitetural favorece um atributo em detrimento de outro. Consistência vs. disponibilidade. Simplicidade vs. flexibilidade. Performance vs. manutenibilidade.
Por que aprender: Buscar a solução "perfeita" paralisa. Ex: O Google Spanner prometia "o melhor dos dois mundos" (consistência + disponibilidade) — mas custou US$1B+ em R&D e infraestrutura global com relógios atômicos. Você não tem esse budget.
Conceitos-chave: CAP Theorem revisitado, PACELC, Trade-off matrix, "Good enough" engineering
O que é: Mais performance custa mais dinheiro (servidores maiores, caching, CDN). O ponto ótimo é onde o custo marginal de performance excede o benefício.
Por que aprender: Over-provisionar é tão ruim quanto under-provisionar. Ex: Uma startup pagando US$5k/mês em AWS para servir 100 usuários está queimando dinheiro. Um Redis de US$50/mês resolve o bottleneck.
Conceitos-chave: Cost per request, Right-sizing, Reserved vs. spot instances, CDN ROI, Caching economics
O que é: Entregar rápido acumula dívida técnica. Refatorar tudo atrasa features. O equilíbrio muda conforme o estágio do produto.
Por que aprender: Dívida técnica é como dívida financeira — controlada é ferramenta, descontrolada é falência. Ex: O Facebook tinha o lema "move fast and break things" até 2014. Quando tinham 1.3B usuários, mudaram para "move fast with stable infrastructure" porque quebrar coisas custava muito.
Conceitos-chave: Technical debt quadrant (Fowler), Quality gates, Definition of done, Refactoring budget (20% rule)
O que é: Mais segurança geralmente significa mais atrito para o usuário. MFA é mais seguro mas adiciona passos. Zero Trust é ideal mas complexo de implementar.
Por que aprender: Segurança que ninguém usa não protege ninguém. Ex: O NIST mudou suas guidelines de senha em 2017 — parou de exigir senhas complexas com símbolos porque usuários anotavam em post-its. Senhas longas e simples (passphrases) são mais seguras na prática.
Conceitos-chave: Risk-based authentication, Progressive security, Passwordless auth, Biometrics, Security UX
O que é: Sistemas mais flexíveis são mais complexos. Plugin systems, feature flags, configuração dinâmica — tudo tem custo cognitivo e operacional.
Por que aprender: "E se precisarmos mudar isso?" é a pergunta que mais gera over-engineering. Ex: YAGNI na prática — 80% das features "para o futuro" nunca são usadas (IBM Research). Cada abstração prematura é código para manter.
Conceitos-chave: YAGNI rigoroso, Extension points seletivos, Configuration vs. code, Plugin architecture cost
O que é: Em sistemas distribuídos, durante partições de rede, você escolhe consistência (rejeitar requests) ou disponibilidade (servir dados potencialmente stale).
Por que aprender: A escolha depende do domínio. Banco precisa de consistência. E-commerce pode tolerar catálogo levemente desatualizado. Ex: O DynamoDB do Amazon oferece "eventually consistent reads" (mais rápido, mais barato) e "strongly consistent reads" (mais lento, mais caro) — você escolhe por operação.
Conceitos-chave: Strong vs. eventual consistency, Conflict resolution (last-write-wins, CRDT), Read-your-writes, Tunable consistency
O que é: Método estruturado: (1) listar opções, (2) definir critérios, (3) avaliar cada opção contra cada critério, (4) documentar a decisão e seus motivos.
Por que aprender: Decisões arquiteturais sem método viram "achismo do mais sênior". Ex: No ATAM (Architecture Tradeoff Analysis Method), stakeholders avaliam cenários de qualidade contra a arquitetura proposta — as discordâncias revelam riscos ocultos.
Conceitos-chave: ATAM, Weighted decision matrix, Spike/PoC, Time-boxed experiments, Reversibility score
Ver Completo
Módulo 2.3 ~35 min

🛠️ Escolhendo a Stack Certa

Tecnologia é meio, não fim — como escolher sem cair no hype

O que é: Toda tecnologia passa pelo Gartner Hype Cycle: trigger, pico de expectativas infladas, vale da desilusão, slope of enlightenment, platô de produtividade.
Por que aprender: Adotar no pico é arriscado; adotar no platô é seguro mas tardio. Ex: GraphQL em 2018 era hype puro. Em 2024, é uma ferramenta madura usada onde faz sentido (mobile-first apps) e ignorada onde não faz (APIs internas simples).
Conceitos-chave: Gartner Hype Cycle, Technology Radar (ThoughtWorks), Boring technology theory, Lindy Effect
O que é: Stack que ninguém conhece é stack que ninguém mantém. O conhecimento existente do time é a restrição mais importante e mais ignorada.
Por que aprender: Contratar para uma stack exótica é caro e demorado. Ex: A Etsy deliberadamente escolheu PHP (que muitos consideram "inferior") porque todo dev do mercado conhece. Resultado: time de 200+ devs contratados rapidamente, todos produtivos em semanas.
Conceitos-chave: Hiring funnel, Ramp-up time, Bus factor, Polyglot pragmatism, Training investment vs. hiring
O que é: Uma linguagem/framework é tão boa quanto seu ecossistema. Bibliotecas maduras, documentação abundante, comunidade ativa.
Por que aprender: Ecossistema fraco = reinventar rodas constantemente. Ex: Node.js venceu não por ser "melhor" que alternativas, mas porque o npm tem 2M+ pacotes. Python domina IA porque tem NumPy, TensorFlow, PyTorch. O ecossistema é o moat.
Conceitos-chave: Package ecosystem maturity, Community health metrics, Documentation quality, Long-term support (LTS), Vendor backing
O que é: TCO inclui licença, infraestrutura, treinamento, contratação, manutenção, oportunidade. Um banco "gratuito" pode custar mais que um pago se exigir DBA dedicado.
Por que aprender: Decisões baseadas apenas em custo de licença são míopes. Ex: Migrar de Oracle (caro) para PostgreSQL ("grátis") parece óbvio — mas se seu time não sabe PostgreSQL e precisa 3 meses de migração + treinamento, o TCO no primeiro ano pode ser maior.
Conceitos-chave: License cost, Infrastructure cost, People cost, Opportunity cost, Migration cost, Vendor lock-in premium
O que é: Stack prática calibrada para pequenos times que constroem produtos educacionais e automações com IA: n8n para orquestração, Claude para geração, Supabase para dados, HTML estático para front.
Por que aprender: Não precisa de React, não precisa de Kubernetes, não precisa de microserviços. Ex: A INEMA roda cursos para milhares de alunos com HTML estático servido via CDN — custo zero de hosting, performance máxima, zero dependências JavaScript.
Conceitos-chave: n8n como orquestrador, Claude Code para geração, Supabase (auth + DB + storage), HTML estático vs. SPA, CDN-first deployment
O que é: Como migrar de uma stack para outra sem parar o sistema. Strangler fig, parallel run, canary migration.
Por que aprender: Reescritas big-bang falham 70% das vezes (Standish Group). Migração gradual é a única abordagem confiável. Ex: O LinkedIn migrou de Java monolítico para microsserviços usando Strangler Fig — cada novo feature era um novo serviço, o monolito encolhia gradualmente por 3 anos.
Conceitos-chave: Strangler Fig Pattern, Blue-green deployment, Canary releases, Feature flags como kill switch, Database migration strategies
O que é: Framework prático de 10 perguntas: (1) Time conhece? (2) Contratamos fácil? (3) Comunidade ativa? (4) Resolve nosso problema principal? (5) TCO aceitável? (6) Lock-in gerenciável? (7) Escala para nosso horizonte? (8) Segura o suficiente? (9) Podemos migrar depois? (10) Testamos com PoC?
Por que aprender: Decisão de stack sem framework vira debate emocional. Ex: "Vamos usar Rust!" — É rápido, sim. Mas alguém do time sabe Rust? Vamos contratar devs Rust? Em quanto tempo? A que custo?
Conceitos-chave: Stack scorecard, PoC time-boxed (2 semanas max), Kill criteria, Reversibility assessment
Ver Completo
Módulo 2.4 ~30 min

📝 ADRs e Documentação de Decisão

Architecture Decision Records — a memória do projeto

O que é: Architecture Decision Records são documentos curtos que registram decisões arquiteturais significativas: contexto, decisão, consequências. Vivem no repositório junto ao código.
Por que aprender: Sem ADRs, cada novo dev pergunta "por que fizeram assim?" e ninguém lembra. Ex: O Spotify tem 1000+ ADRs públicos internamente. Quando alguém questiona uma decisão, aponta para o ADR — com contexto, alternativas rejeitadas e trade-offs documentados.
Conceitos-chave: Context, Decision, Consequences, Status (proposed/accepted/deprecated/superseded)
O que é: Template: Título, Data, Status, Contexto (o problema), Decisão (o que escolhemos), Consequências (positivas e negativas), Alternativas (o que rejeitamos e por quê).
Por que aprender: ADRs ruins são piores que nenhum ADR — dão falsa sensação de documentação. Ex: "Decidimos usar PostgreSQL" não é um ADR. "Escolhemos PostgreSQL para o serviço de pagamentos porque precisamos de transações ACID e o time já tem expertise. Alternativa rejeitada: MongoDB, por falta de transações multi-document na época" — isso é um ADR.
Conceitos-chave: Michael Nygard's template, MADR (Markdown ADR), Decisão com "because", Tamanho ideal (1 página)
O que é: ADRs são para decisões significativas: escolha de banco, estilo arquitetural, protocolo de comunicação, estratégia de deploy. Não para "usar tab ou espaço".
Por que aprender: Over-documentation mata a prática. Ex: Regra prática — se a decisão: (1) é difícil de reverter, (2) afeta múltiplos times, (3) tem trade-offs não-óbvios, ou (4) alguém vai perguntar "por quê?" daqui a 6 meses — escreva um ADR.
Conceitos-chave: Significance threshold, Reversibility criterion, Impact radius, "Would a new team member ask about this?"
O que é: ADRs vivem em docs/decisions/ ou docs/adr/ no repositório. Numerados sequencialmente. Versionados com git. Linked nos PRs que implementam a decisão.
Por que aprender: ADRs fora do repo são ignorados. Ex: Confluência é onde documentação vai para morrer. No repo, o ADR aparece no PR review, no blame, no log — é parte do fluxo.
Conceitos-chave: docs/adr/ convention, Sequential numbering, Status lifecycle, ADR tools (adr-tools CLI, Log4brains)
O que é: ADRs têm ciclo de vida: Proposed (em discussão), Accepted (aprovado), Deprecated (não mais relevante), Superseded (substituído por novo ADR).
Por que aprender: Decisões mudam — e isso é ok. O ADR antigo não é "errado", era certo para o contexto da época. Ex: ADR-0005: "Usar REST para todas as APIs". 2 anos depois, ADR-0023: "Usar gRPC para comunicação interna (substitui ADR-0005 para serviço-a-serviço)" — a história completa está preservada.
Conceitos-chave: Status transitions, Superseding vs. deprecating, Linking ADRs, Decision timeline
O que é: ADRs não são só documentação — são ferramenta de alinhamento. Um ADR "proposed" é um RFC (Request for Comments) que o time revisa antes da implementação.
Por que aprender: Times distribuídos não podem depender de reuniões para alinhar. Ex: O Thoughtworks usa ADRs como RFCs — o autor propõe, o time comenta no PR, ajustes são feitos, e quando mergeia está aceito. Zero reuniões para 80% das decisões.
Conceitos-chave: ADR as RFC, Async decision-making, Comment period, Consensus vs. consent, Escalation path
O que é: Periodicamente revisar ADRs à luz de novos dados: a decisão funcionou? Os trade-offs se confirmaram? Precisa ser revisada?
Por que aprender: Decisões envelhecem. O que era correto com 10 usuários pode ser errado com 10M. Ex: Architecture fitness functions — testes automatizados que verificam se a arquitetura ainda atende seus atributos de qualidade. Se a latência P99 ultrapassou o SLO, talvez o ADR que escolheu comunicação síncrona precise ser revisitado.
Conceitos-chave: Architecture fitness functions, Quarterly review, Decision effectiveness metrics, Trigger-based review
Ver Completo
Módulo 2.5 ~35 min

🔄 Migração e Evolução

Sistemas vivos mudam — aprenda a evoluir sem quebrar

O que é: Novo sistema cresce ao redor do antigo, como uma figueira estranguladora. Cada nova feature vai para o sistema novo. O antigo encolhe até desaparecer.
Por que aprender: Reescritas big-bang falham porque o sistema antigo ainda precisa de manutenção durante a reescrita. Ex: Martin Fowler documentou o padrão no caso do The Guardian: migraram de Java para Scala/Play um módulo por vez, ao longo de anos, sem downtime.
Conceitos-chave: Proxy/router layer, Gradual cutover, Feature parity tracking, Rollback safety, Timeline expectations (anos, não meses)
O que é: Introduzir uma abstração entre consumidores e a implementação que vai mudar. Trocar a implementação por trás da abstração. Remover a abstração quando a migração estiver completa.
Por que aprender: Permite migrar componentes internos sem afetar quem os usa. Ex: O Flickr migrou de MySQL para PostgreSQL usando Branch by Abstraction — criaram uma interface de "data store", rodaram ambos em paralelo, compararam resultados, e switcharam.
Conceitos-chave: Abstraction layer, Parallel run, Result comparison, Gradual cutover, Cleanup phase
O que é: Deploy da nova versão para um pequeno percentual de usuários (1-5%). Monitorar métricas. Se ok, aumentar gradualmente. Se não, rollback instantâneo.
Por que aprender: Testes em staging não pegam tudo. Produção tem dados, carga e comportamentos únicos. Ex: O Google faz canary de toda mudança no Gmail — 0.1% dos usuários primeiro, por 24h. Se error rate > baseline, auto-rollback. Protege os outros 1.8B usuários.
Conceitos-chave: Progressive rollout (1% → 5% → 25% → 100%), Metric-based promotion, Automatic rollback triggers, Observability requirements
O que é: Migrar banco é mais difícil que migrar código. Envolve schema changes, data migration, dual-write, shadow traffic.
Por que aprender: Banco errado é a decisão mais cara para reverter. Ex: O GitHub migrou de MySQL para Vitess (MySQL sharded) sem downtime para 100M+ repositórios. Usaram dual-write por 6 meses, comparando resultados antes de cortar.
Conceitos-chave: Dual-write pattern, Shadow traffic, Schema versioning, Backward-compatible migrations, Zero-downtime migrations
O que é: Conditional logic que ativa/desativa features sem deploy. Permite trunk-based development, A/B testing, e kill switch para features problemáticas.
Por que aprender: Feature flags desacoplam deploy de release. Ex: O Facebook deploya código 3x/dia para 3B+ usuários — tudo atrás de feature flags (Gatekeeper). Se algo quebra, desliga o flag em segundos, sem rollback de deploy.
Conceitos-chave: Release flags vs. experiment flags vs. ops flags, Flag lifecycle, Technical debt de flags, LaunchDarkly vs. custom
O que é: Testes que verificam se a arquitetura continua atendendo seus atributos de qualidade. Latência < 200ms? Zero dependências circulares? Cobertura > 80%?
Por que aprender: Sem fitness functions, degradação arquitetural é invisível até explodir. Ex: O ArchUnit (Java) testa que "nenhum controller importa repositório diretamente" — se alguém viola a camada, o build quebra. Degradação bloqueada na CI.
Conceitos-chave: ArchUnit, NetArchTest, Dependency rules, Performance budgets, Automated architecture compliance
O que é: Arquitetura que suporta mudanças incrementais guiadas em múltiplas dimensões. Não é "arquitetura que prevê o futuro" — é "arquitetura que aceita que não prevemos o futuro".
Por que aprender: O único constante é mudança. Arquitetura que resiste a mudança é dívida técnica. Ex: A Netflix fez 7 grandes migrações arquiteturais em 15 anos (datacenter → AWS → microsserviços → edge → serverless parcial) — cada uma incremental, nenhuma big-bang.
Conceitos-chave: Guided incremental change, Last Responsible Moment, Fitness functions, Sacrificial architecture, "Make the change easy, then make the easy change"
Ver Completo
← Fundamentos Próxima: IA e Automação →