Melhores Práticas para Estudos de Caso
Anote a versão do Postgres e o provedor de nuvem; reproduza em novas versões principais. Use esta lista ao criar ou consumir estudos de caso internos do Postgres.
Como Usar Esta Lista
- Trate os estudos de caso como runbooks reproduzíveis, não como histórias de marketing.
- Atualize ou arquive quando versões principais do Postgres ou extensões tornarem os detalhes obsoletos.
- Redija nomes de clientes; mantenha números e topologia honestos.
- Vincule cada estudo a ADRs e tickets de migração, quando possível.
A - Metadados
- Versão principal.secundária do Postgres fixada. Exemplo: PostgreSQL 18.4, não "última".
- Provedor de nuvem e topologia anotados. RDS, Cloud SQL, auto-gerenciado, operador K8s.
- Versões de extensões listadas. pgvector, PostGIS, pgaudit com semver.
- Escala de dados incluída. Contagens de linhas, tamanho do PGDATA, ordem de magnitude de QPS.
- Data ou trimestre do evento. Leitores saberão a atualidade das lições.
B - Rigor Antes/Depois
- Tabela de métricas antes e depois. Latência, custo, lag, contagem de incidentes.
- Snippets de EXPLAIN ou resumo do plano. Não apenas "índice adicionado".
- Alternativas de decisão documentadas. Por que pg_upgrade vs replicação lógica.
- Caminhos falhos mencionados. O que foi tentado e rejeitado constrói confiança.
C - Segurança e Conformidade
- Sem credenciais de produção ou nomes de host. Use padrões
primary.internal. - PII redigido em SQL de exemplo. UUIDs e e-mails sintéticos.
- Dados regulamentados destacados. Limites PCI, HIPAA no diagrama de arquitetura.
D - Manutenção
- Reproduzir em nova versão principal em até 12 meses após o lançamento. Valide se os passos ainda se aplicam.
- Proprietário atribuído por arquivo de estudo de caso no git. Não página de wiki órfã.
- Links relacionados apontam para slugs de seção atuais. Corrija links quebrados no mesmo PR das edições.
- Lições destiladas em política acionável. Regra do conselho ou lint, não "vibes".
FAQs
Qual deve ser o tamanho de um estudo de caso?
2-4 telas: contexto, decisão, métricas, lições. Apêndices mais longos em runbooks vinculados.
Cliente real vs. composto?
Composto está OK se rotulado; nunca fabrique métricas.
Devemos incluir valores em dólares?
Sim, quando o financeiro aprovou o compartilhamento; intervalos OK se o exato for sensível.
Quem aprova a publicação?
Líder técnico + jurídico para menções de clientes; segurança para exposição da arquitetura.
Como versionar estudos de caso?
O histórico do Git é a fonte da verdade; adicione a data de "Última revisão" no parágrafo introdutório.
Incluir upgrades falhos?
Especialmente valioso; marque a gravidade e o resultado do rollback claramente.
Diagramas são necessários?
ASCII ou diagrama vinculado para topologia; ajuda a reproduzir em novo provedor.
Traduzir para es depois?
Inglês é o caminho canônico; translate-es espelha o mesmo slug um para um.
Link para gravações de vídeo?
Opcional; resumo da transcrição ainda é necessário para busca e lint.
O que devo ler a seguir?
Navegue pelas arquiteturas de referência nesta seção para modelos.
Relacionados
- Referência: SaaS Multi-Tenant - Modelo SaaS
- Antes/Depois: Upgrade de Versão Principal - narrativa de upgrade
- Antes/Depois: Vitória na Otimização de Consultas - narrativa de desempenho
- Noções Básicas de Governança - padrões de documentação
Versões da Stack: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x, e PostGIS 3.5+.