CZANIXCada decisão técnica tem contexto, custo e critério. Quando alguém perguntar "qual eu uso?", a resposta aqui não é "depende" — é uma tabela com os critérios para você decidir.
"Não é porque sempre foi feito assim que é o certo, ou o melhor."
— Cesar Zanis
Quando usar
Resposta imediata necessária. CRUD simples. Volume baixo a médio. API pública consumida por browsers.
Quando NÃO usar
Operação longa (>2s). Fanout para múltiplos consumidores. Tolerância a consistência eventual.
Custo do Trade-off
Acoplamento temporal. Se o destino cai, você cai junto.
Quando usar
Operações longas. Desacoplamento entre times. Retry automático necessário. Picos de carga absorvíveis.
Quando NÃO usar
Quando o chamador precisa da resposta imediatamente (login, validação, checkout).
Custo do Trade-off
+20-30% complexidade inicial. Dead-letter, monitoramento de fila, idempotência. Retorno: resiliência real.
Quando usar
Comunicação interna inter-serviço de alta frequência. Contratos fortemente tipados. Streaming bidirecional.
Quando NÃO usar
APIs públicas consumidas por browsers (suporte nativo limitado). Times sem experiência com protobuf.
Custo do Trade-off
+15% curva de aprendizado. Retorno: latência menor, contratos binários versionados.
Quando usar
Endpoints de alta frequência. Queries complexas com JOINs. Requisito de latência <100ms. Controle de plano de execução.
Quando NÃO usar
CRUD administrativo simples. Prototipagem rápida onde velocidade de desenvolvimento importa mais.
Custo do Trade-off
+15% código manual de mapeamento. Retorno: performance previsível, zero surpresas de SQL gerado.
Quando usar
CRUD de backoffice com baixo volume. Prototipagem. Equipes com pouca experiência em SQL.
Quando NÃO usar
Sync mobile, relatórios pesados, qualquer endpoint com requisito de latência apertado.
Custo do Trade-off
Conveniência máxima. Risco: queries geradas subótimas aparecem em produção sob carga.
Quando usar
Qualquer tabela transacional com >10k registros. APIs públicas. Quando segurança contra enumeração importa.
Quando NÃO usar
Tabelas de lookup/constantes (<10k linhas) onde UUID como PK é aceitável por simplicidade.
Custo do Trade-off
+1 coluna + índice UNIQUE. Retorno: performance de B-Tree intacta + exposição segura.
Quando usar
Tabelas pequenas (<10k linhas). Sistemas distribuídos com UUID v7 (ordenado por tempo). ID pré-gerado no client.
Quando NÃO usar
Tabelas transacionais grandes (>100k). A fragmentação do B-Tree vai custar caro em 6 meses.
Custo do Trade-off
Simplicidade de 1 coluna. Risco: fragmentação de índice clustered em volume.
Quando usar
Tabelas transacionais. Dados com valor histórico ou de BI. Auditoria regulatória. Conformidade com LGPD.
Quando NÃO usar
Tabelas temporárias (logs de debug, staging). Dados efêmeros sem valor de negócio.
Custo do Trade-off
+1 coluna + filtro global obrigatório em todos os SELECTs. Retorno: reversibilidade e integridade histórica.
Quando usar
Sessões e tokens. Contadores em tempo real. Dados compartilhados entre instâncias. TTL obrigatório. Chaves pequenas (<1KB).
Quando NÃO usar
Payloads grandes (>5KB). PDFs. Respostas JSON completas de API. Dados que mudam raramente.
Custo do Trade-off
Custo de RAM cloud. Regra: se TTL >1h ou valor >1KB, questione se Redis é o lugar certo.
Quando usar
Assets estáticos. Respostas de API imutáveis (catálogos versionados). Imagens. Páginas sem personalização.
Quando NÃO usar
Dados personalizados por usuário. Dados que mudam em tempo real.
Custo do Trade-off
Quase grátis. Complexidade: invalidação. Use ETags ou versionamento de URL.
Quando usar
Dados que mudam a cada request. Custo de inconsistência maior que custo de latência. Queries <100ms.
Quando NÃO usar
Queries pesadas (>500ms) que retornam o mesmo resultado por minutos.
Custo do Trade-off
Zero complexidade. Custo: latência e carga no banco. Aceitável se o contexto permitir.
Quando usar
Sistema <5k linhas. Sem consumidores externos. Time domina o domínio completamente. Custo de migração documentado.
Quando NÃO usar
Sistema em produção com múltiplos consumidores. Regras de negócio não documentadas. Time que não domina o domínio.
Custo do Trade-off
Risco altíssimo de perder regras implícitas. Só justificável com decisão consciente e documentada.
Quando usar
Sistema em produção com consumidores ativos. Migração com rollback possível a qualquer ponto. Time não pode parar.
Quando NÃO usar
Sistema trivial sem consumidores (não precisa dessa cerimônia para 3 endpoints).
Custo do Trade-off
+30% tempo vs reescrita pura. Retorno: zero risco de downtime, migração invisível para o usuário.
Quando usar
Framework ainda suportado. Equipe produtiva. Custo de migração >benefício claro.
Quando NÃO usar
Framework descontinuado. Equipe improdutiva. Débito técnico crescendo mais rápido que features.
Custo do Trade-off
Menor custo imediato. Risco: débito acumula silenciosamente. Exige revisão semestral honesta.
Quando usar
Boilerplate, CRUD, testes, código que segue padrão já estabelecido no projeto.
Quando NÃO usar
Algoritmo de negócio crítico que ninguém no time entende bem o suficiente para revisar o output.
Custo do Trade-off
Velocidade 3-5x. Risco: se você não revisa, planta bomba-relógio em produção.
Quando usar
Explorar alternativas, gerar rascunhos de ADR, analisar trade-offs, revisar proposta antes de apresentar.
Quando NÃO usar
Decisão final. A IA propõe, o humano decide. Nunca delegue decisão arquitetural para IA.
Custo do Trade-off
Perspectiva ampla. Limite: IA não conhece o contexto político, organizacional ou histórico do seu sistema.
Quando usar
Código com segredos, logs com dados sensíveis, análise de PII, contexto que não pode sair da máquina.
Quando NÃO usar
Quando o modelo local não tem capacidade para a tarefa. Prefira cloud para raciocínio complexo.
Custo do Trade-off
Segurança total. Custo: qualidade inferior em tarefas que exigem raciocínio profundo.
Se você não consegue preencher a coluna "quando NÃO usar", você ainda não entendeu o trade-off. Entender o custo é parte da decisão.
— Czanix Tech ReferenceEstá na dúvida em um trade-off específico do seu contexto?
Fale com o Nix →