Tomada de Decisão Técnica
Tech leads de Solana enfrentam bifurcações de alto risco: Anchor vs Pinocchio, chaves custodiais vs não custodiais, programas upgradeable vs imutáveis. Boas decisões enquadram opções, pontuam trade-offs explicitamente e comprometem com owner documentado e data de revisão.
Como Usar Esta Lista
- Use cada template de decisão quando dois engenheiros sênior discordam por mais de uma reunião
- Classifique escolhas para seu contexto - "Melhor" assume DeFi de produção, não hackathon
- Registre resultado em ADR em até 48 horas
- Defina data de revisão do ADR quando versões menores de Agave ou Anchor forem lançadas
Decisão 1: Anchor vs Nativo (Pinocchio) para Novo Programa
Cenário: Programa greenfield; equipe conhece Anchor 0.32.1; orçamento de CU pode importar em escala.
| Rank | Escolha | Abordagem |
|---|---|---|
| Melhor | Anchor | IDL, testes, constraints; entregue em um sprint |
| 2º | Pinocchio / nativo | Caminho quente crítico em CU após profiling provar necessidade |
| 3º | Steel | Leve quando overhead do Anchor alto demais mas alguma ergonomia desejada |
Escolha errada: Nativo no dia um para "evitar bloat" sem dados de CU - dobra superfície de revisão de segurança.
Por que melhor é melhor: Macros de constraint do Anchor codificam verificações Sealevel; firmas de auditoria reconhecem padrões; velocidade da equipe importa pré-PMF.
Decisão 2: Programa Upgradeable vs Imutável
Cenário: Lançando vault de lending com depósitos de usuários.
| Rank | Escolha | Abordagem |
|---|---|---|
| Melhor | Upgradeable + multisig + pause | Corrija bugs; pratique rollback |
| 2º | Imutável | Só após auditorias e sem mudanças de lógica planejadas |
| 3º | Upgradeable com hot key | Nunca para fundos de usuário em produção |
Escolha errada: Imutável no lançamento "para parecer descentralizado" - não pode corrigir exploit sem migração.
Por que melhor é melhor: Exploits na Solana movem rápido; upgrade multisig com builds verificáveis equilibra confiança e segurança.
Decisão 3: SDK de Cliente - @solana/kit vs web3.js Legado
Cenário: Novo dApp Next.js em 2026.
| Rank | Escolha | Abordagem |
|---|---|---|
| Melhor | @solana/kit 7.0.0 | RPC tipado, codecs, tree-shakeable |
| 2º | Cliente TS Anchor | CPI Anchor pesado do mesmo repo |
| 3º | web3.js v1 | Apenas manutenção legada |
Escolha errada: Projeto novo em padrões não mantidos - custo de migração atinge no crunch de lançamento.
Por que melhor é melhor: Kit alinha com RPC Agave 4.1.1 e direção de longo prazo da Solana Foundation.
Decisão 4: RPC - Provedor Único vs Múltiplo
Cenário: App de carteira em produção; 10k DAU.
| Rank | Escolha | Abordagem |
|---|---|---|
| Melhor | Write primário + failover read secundário | SWQoS no caminho de envio |
| 2º | Provedor premium único | Aceitável abaixo de 2k DAU com SLA |
| 3º | RPC público | Apenas dev |
Escolha errada: RPC mainnet público no dia do mint - rate limits viram sua indisponibilidade.
Por que melhor é melhor: Landing e disponibilidade de leitura dominam tickets de suporte; failover é mais barato que MTTR de incidente.
Decisão 5: Indexador - Construir vs Comprar
Cenário: Precisa de histórico além de getSignaturesForAddress de RPC.
| Rank | Escolha | Abordagem |
|---|---|---|
| Melhor | Indexador gerenciado (Helius, etc.) | Entregue produto; SLAs |
| 2º | Yellowstone gRPC self-host | Escala ou parsing customizado |
| 3º | Poll RPC em cron | Apenas protótipo |
Escolha errada: Loops GPA em API route em escala - 429 na própria produção.
Por que melhor é melhor: Tempo de engenharia melhor gasto em segurança de programa do que em indexador ops, salvo competência central.
Decisão 6: Testes - LiteSVM vs Test Validator
Cenário: CI para PRs de programa Anchor.
| Rank | Escolha | Abordagem |
|---|---|---|
| Melhor | LiteSVM 0.6.x em CI | Rápido, determinístico |
| 2º | Surfpool 0.12.0 | Cenários de clone de conta mainnet |
| 3º | solana-test-validator | Debug manual local |
Escolha errada: Devnet como gate de CI - instável e rate-limited.
Por que melhor é melhor: Testes sub-segundo habilitam regressão de segurança em todo PR.
FAQs
Quantas opções por decisão?
Máximo três no doc de decisão; mais causa fadiga.
Quem decide no final?
Tech lead ou arquiteto; input de PM em trade-offs visíveis ao usuário.
Quando revisitar decisão?
Data de revisão do ADR ou upgrade material de Agave/Anchor.
Disagree-and-commit?
Registre dissidência no ADR; quem apoia é owner das métricas de resultado.
Spikes antes de decidir?
Time-box de 2-3 dias para incógnitas de CU ou landing.
Governança comunitária?
Votos de token para parâmetros de protocolo; ADRs de engenharia para implementação.
Sinais de fadiga de decisão?
Mesmo debate todo sprint - ADR ausente ou owner pouco claro.
Input de engenheiro júnior?
Obrigatório em design review; owner da decisão ainda é sênior nomeado.
Escalar quando?
Irreversível + alto risco de fundos + discordância após duas reuniões.
Localização do template?
docs/adr/ no repo; link do README de arquitetura.
Relacionado
- Architecture Decision Records (ADRs) - documentar resultados
- Conduzindo Design Reviews - facilitar debate
- Lidando com Discordâncias Técnicas - desescalação
Versões da stack: Esta página foi escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0 e LiteSVM 0.6.x.