What Works Today May Fail Tomorrow
Aussi en 19 langues
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Deutsch (Schweiz)
Chapitre 7 de Data Architect, et le début de la Partie 2 : Architecturer à grande échelle. Précédent : Données maîtres et identité.
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 (s'ouvre dans un nouvel onglet)). 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. ⟲
La partie 1 nous a appris à voir. La partie 2 met du poids sur l’architecture. Ce chapitre est le premier test : l’ossature peut-elle porter les zéros ?
Image generated with AI. ⟲
Les idées de ce chapitre
Section intitulée « Les idées de ce chapitre »- Planifiez avec le Nombre de zéros, en tenant compte de la croissance et de toute la durée de conservation, pas du volume d’aujourd’hui. Un million de parents avec huit enfants chacun, ce n’est pas un problème d’un million d’enregistrements.
- What works today may fail tomorrow. Volume slows sharing, locking, list views, reports, loads and deletes, not only queries. ⟲
- Concevez proprement, puis reculez délibérément quand le volume vous en donne une raison, et ne faites pas du CRM principal votre entrepôt de données.
- 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. ⟲
- Les propriétaires à fort volume restent hors de la hiérarchie des rôles, ou dans leur propre rôle stable au sommet, et hors des groupes des règles de partage.
- Qui possède les enregistrements créés par des machines dépend de l’importance de la propriété pour le partage.
- À grande échelle, un réalignement de la sécurité est une opération sur les données : différez les calculs de partage, répétez dans un sandbox complet, recalculez une seule fois. Et ne rendez jamais des données publiques parce que le privé est plus lent.
- Si vous n’archivez pas aujourd’hui, archiverez-vous un jour ? Décidez de la suppression dès le premier jour, sauvegardez avant de supprimer et gardez les archives retrouvables.
- Que les données archivées restent accessibles aux agents ou non, c’est au métier d’en décider.
Where volume causes problems
Section intitulée « Where volume causes problems »| Ce qui grandit | Ce que cela ralentit | Où c’est traité |
|---|---|---|
| Les enregistrements d’un objet | Requêtes, vues de liste, rapports | Module 1 ; chapitre 8 |
| Les enfants sous un parent, les enregistrements sous un propriétaire | Verrous, recalcul du partage | Module 2 |
| Children under one master-detail parent | Locking, roll-ups, cascade delete, a hard-to-undo choice | Module 2 |
| Les utilisateurs, rôles, groupes et règles | Recalcul des accès, réalignements | Module 3 |
| L’historique que personne n’utilise | Tout, plus le stockage et le risque | Module 4 |
Le parcours de ce chapitre
Section intitulée « Le parcours de ce chapitre »Quatre modules, chacun autonome.
- 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. ⟲
- Quand le volume rencontre le modèle de partage. La propriété comme levier d’accès, des hiérarchies stables, les calculs de partage différés, le verrouillage granulaire et l’isolement des partenaires à grande échelle.
- Si vous n’archivez pas aujourd’hui…. Le cycle de vie dès le premier jour, la sauvegarde avant la suppression, l’emplacement de l’archive, l’archivage en trois étapes, et les agents face aux données anciennes.
Ce que l’architecte décide ici
Section intitulée « Ce que l’architecte décide ici »- Jusqu’où chaque objet grandit, avec la croissance et sur sa durée de conservation.
- Où les enregistrements se concentrent, et quelles concentrations sont dangereuses.
- Ce que signifie la propriété pour chaque objet à fort volume, y compris ceux que créent les agents.
- Comment le modèle d’accès passe à l’échelle, et comment les grands réalignements sont planifiés.
- Comment les données sortent : archivage, purge, sauvegarde, et qui peut encore les retrouver.
Au-delà de l’examen : les agents ajoutent des zéros. Ils peuvent créer dix enregistrements là où une personne en créait un, les posséder tous par défaut, récupérer des données plus vite que quiconque et atteindre les archives, à moins que quelqu’un ne décide qu’ils ne le doivent pas. Chaque module se termine par ce que l’IA change dans sa part du problème.
Pour aller plus loin
Section intitulée « Pour aller plus loin »- Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (s'ouvre dans un nouvel onglet), checked 2026-11-01. ⟲
- Salesforce Developers, Designing Record Access for Enterprise Scale (s'ouvre dans un nouvel onglet) (Winter ‘27), checked 2026-11-01. ⟲
- Salesforce Developers, Best Practices for Deployments with Large Data Volumes (s'ouvre dans un nouvel onglet) (Winter ‘27), checked 2026-11-01. ⟲