What Works Today May Fail Tomorrow

🌐 Também em 19 idiomas

English · Español · 日本語 · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)

Traduzido por IA. Ainda não revisado pela comunidade. Ler em inglês Esta seção mudou em inglês e ainda não foi traduzida de novo. (16)

Capítulo 7 de Data Architect, e o início da Parte 2: Arquitetando em 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 em uma nova aba)). 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. ⟲

Clique para ampliar

A Parte 1 nos ensinou 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

• Planeje com o Número de Zeros, considerando 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 registros.
• 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 papéis, ou num papel próprio e estável no topo, e fora dos grupos das regras de compartilhamento.
• Quem é dono dos registros criados por máquinas depende de a propriedade importar para o compartilhamento.
• Em escala, um realinhamento de segurança é uma operação de dados: adie os cálculos de compartilhamento, ensaie num sandbox completo, recalcule uma vez. E nunca torne dados públicos porque o privado é mais lento.
• Se você não arquiva hoje, algum dia vai arquivar? Decida a exclusão no primeiro dia, faça backup antes de excluir e mantenha os arquivos encontráveis.
• Se os dados arquivados continuam ao alcance dos agentes é decisão do negócio.

Where volume causes problems

O que cresce	O que fica mais lento	Onde é tratado
Registros num objeto	Consultas, exibições de lista, relatórios	Módulo 1; capítulo 8
Filhos sob um pai, registros sob um proprietário	Bloqueios, recálculo do compartilhamento	Módulo 2
Children under one master-detail parent	Locking, roll-ups, cascade delete, a hard-to-undo choice	Module 2
Usuários, papéis, 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

Quatro módulos, cada um se sustenta sozinho.

1. 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. ⟲
2. 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. ⟲
3. O volume encontra o modelo de compartilhamento. A propriedade como alavanca de acesso, hierarquias estáveis, cálculos de compartilhamento adiados, bloqueio granular e isolamento de parceiros em escala.
4. Se você não arquiva hoje…. O ciclo de vida desde o primeiro dia, backup antes de excluir, onde o arquivo fica, o arquivamento em três etapas, e os agentes e os dados antigos.

O que um arquiteto decide aqui

• Quanto cada objeto cresce, com o crescimento e ao longo do período de retenção.
• Onde os registros 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 planejados.
• 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 registros onde uma pessoa criava um, ser donos de todos por padrã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

• Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (abre em uma nova aba), checked 2026-11-01. ⟲
• Salesforce Developers, Designing Record Access for Enterprise Scale (abre em uma nova aba) (Winter ‘27), checked 2026-11-01. ⟲
• Salesforce Developers, Best Practices for Deployments with Large Data Volumes (abre em uma nova aba) (Winter ‘27), checked 2026-11-01. ⟲

Próximo: Arquitetura de consulta e recuperação