What Works Today May Fail Tomorrow
Também em 19 idiomas
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)
Capítulo 7 de Data Architect, e o início da Parte 2: Arquitetar à escala. Anterior: Dados mestres e identidade.
A design can be perfectly reasonable at 70,000 records and completely wrong at 70 million. The object is the same, the fields are the same, the relationships are the same. Add a few zeros, and the architecture changes. ⟲
Start with what the platform is built for. Salesforce’s core database handles “upwards of 1.1 trillion transactions per month,” and Salesforce’s own architects describe it as “optimized for high-performance transactional workloads on structured data” (The Salesforce Platform: Transformed for Tomorrow (abre num novo separador)). It’s built for transactions, on a multitenant database where Salesforce writes the SQL, not you. At small volumes you can ignore the platform’s shape. At large volumes, it reminds you it’s there. ⟲
So I teach large data volumes with a rough ruler, for records in a single object. At about 1 million, there’s a little drag as dashboards and reports show up. Around 10 million, some effect, but still performing. Heading toward 50 million, you notice it: list views take two, three, four seconds. Past 50 million, you’re driving a convertible with your head out the window, and your hair is blown back: you’ve got to be streamlined, and you’ve got to know what you’re doing. At 100 million or more, I start asking a different question: should these records be here at all? That’s a rule of thumb from the community, not a Salesforce limit. The lesson is that volume changes the design, and most large-data-volume problems are design problems: cheap to prevent, expensive to fix. ⟲
A Parte 1 ensinou-nos a ver. A Parte 2 coloca peso na arquitetura. Este capítulo é o primeiro teste: o esqueleto aguenta os zeros?
Image generated with AI. ⟲
As ideias deste capítulo
Seção intitulada “As ideias deste capítulo ”- Planeie com o Número de Zeros, a considerar o crescimento e todo o período de retenção, não a contagem de hoje. Um milhão de pais com oito filhos cada não é um problema de um milhão de registos.
- What works today may fail tomorrow. Volume slows sharing, locking, list views, reports, loads and deletes, not only queries. ⟲
- Projete limpo e depois recue de propósito quando a escala lhe der um motivo, e não transforme o CRM principal no seu data warehouse.
- 10,000 children per parent is a design threshold, not a limit: Salesforce draws the same line, and past about 20,000 I’ve seen visible lag. Account pools work, but hide the placeholder parents. ⟲
- Proprietários de alto volume ficam fora da hierarquia de funções, ou numa função própria e estável no topo, e fora dos grupos das regras de partilha.
- Quem é dono dos registos criados por máquinas depende de a propriedade importar para a partilha.
- À escala, um realinhamento de segurança é uma operação de dados: adie os cálculos de partilha, ensaie numa sandbox completa, recalcule uma vez. E nunca torne dados públicos porque o privado é mais lento.
- Se não arquiva hoje, algum dia vai arquivar? Decida a eliminação no primeiro dia, faça backup antes de eliminar e mantenha os arquivos encontráveis.
- Se os dados arquivados continuam ao alcance dos agentes é decisão do negócio.
Where volume causes problems
Seção intitulada “Where volume causes problems”| O que cresce | O que fica mais lento | Onde é tratado |
|---|---|---|
| Registos num objeto | Consultas, exibições de lista, relatórios | Módulo 1; capítulo 8 |
| Filhos sob um pai, registos sob um proprietário | Bloqueios, recálculo da partilha | Módulo 2 |
| Children under one master-detail parent | Locking, roll-ups, cascade delete, a hard-to-undo choice | Module 2 |
| Utilizadores, funções, grupos e regras | Recálculo do acesso, realinhamentos | Módulo 3 |
| Histórico que ninguém usa | Tudo, mais armazenamento e risco | Módulo 4 |
O caminho por este capítulo
Seção intitulada “O caminho por este capítulo ”Quatro módulos, cada um sustenta-se sozinho.
- When Volume Changes Everything. Built for transactions, the ruler, the Number of Zeros at 30% growth, denormalizing for scale, and keeping analytics out of core. ⟲
- Hot Spots: Ownership, Parent and Lookup Skew. Too many records pointing at one thing, account pools, master-detail at volume (count the children before you choose the relationship), high-volume owners, and who owns agent-created records. ⟲
- O volume encontra o modelo de partilha. A propriedade como alavanca de acesso, hierarquias estáveis, cálculos de partilha adiados, bloqueio granular e isolamento de parceiros à escala.
- Se não arquiva hoje…. O ciclo de vida desde o primeiro dia, backup antes de eliminar, onde o arquivo fica, o arquivamento em três etapas, e os agentes e os dados antigos.
O que um arquiteto decide aqui
Seção intitulada “O que um arquiteto decide aqui ”- Quanto cada objeto cresce, com o crescimento e ao longo do período de retenção.
- Onde os registos se concentram, e quais concentrações são perigosas.
- O que a propriedade significa para cada objeto de alto volume, incluindo os que os agentes criam.
- Como o modelo de acesso escala, e como os grandes realinhamentos são planeados.
- Como os dados saem: arquivamento, expurgo, backup, e quem ainda consegue encontrá-los.
Além do exame: os agentes acrescentam zeros. Eles podem criar dez registos onde uma pessoa criava um, ser donos de todos por omissão, recuperar dados mais rápido que qualquer um e alcançar os arquivos, a menos que alguém decida que não devem. Cada módulo termina com o que a IA muda na sua parte do problema.
Para saber mais
Seção intitulada “Para saber mais ”- Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (abre num novo separador), checked 2026-11-01. ⟲
- Salesforce Developers, Designing Record Access for Enterprise Scale (abre num novo separador) (Winter ‘27), checked 2026-11-01. ⟲
- Salesforce Developers, Best Practices for Deployments with Large Data Volumes (abre num novo separador) (Winter ‘27), checked 2026-11-01. ⟲