Designing for Scale
תוכן זה אינו זמין עדיין בשפה שלך.
Also in 19 languages
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) · Français (Canada) · Deutsch (Schweiz)
Chapter 7 of Data Architect, and the start of Part 2: Architecting at Scale. Previous: Master Data and Identity.
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 (opens in a new tab)). 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.
Part 1 taught us to see. Part 2 puts weight on the architecture. This chapter is the first test: can the bones carry the zeros?
Image generated with AI.
The ideas in this chapter
Section titled “The ideas in this chapter”- Plan with the Number of Zeros, at growth and across the retention period, not today’s count. One million parents with eight children each is not a one-million-record problem.
- What works today may fail tomorrow. Volume slows sharing, locking, list views, reports, loads and deletes, not only queries.
- Design clean, then back off deliberately when scale gives you a reason, and don’t make core CRM your 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.
- High-volume owners stay out of the role hierarchy, or in their own stable role at the top, and out of sharing-rule groups.
- Who owns machine-created records depends on whether ownership matters for sharing.
- At scale, a security realignment is a data operation: defer the sharing calculations, rehearse in a full sandbox, recalculate once. And never make data public because private is slower.
- If you’re not archiving today, are you ever going to archive? Decide deletion on day one, back up before you delete, and keep archives findable.
- Whether archived data stays reachable for agents is the business’s decision.
Where volume causes problems
Section titled “Where volume causes problems”| What grows | What it slows | Where it’s covered |
|---|---|---|
| Records in one object | Queries, list views, reports | Module 1; chapter 8 |
| Children under one parent, records under one owner | Locking, sharing recalculation | Module 2 |
| Children under one master-detail parent | Locking, roll-ups, cascade delete, a hard-to-undo choice | Module 2 |
| Users, roles, groups and rules | Access recalculation, realignments | Module 3 |
| History nobody uses | Everything, plus storage and risk | Module 4 |
The path through this chapter
Section titled “The path through this chapter”Four modules, each standing on its own.
- 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.
- Volume Meets the Sharing Model. Ownership as an access lever, stable hierarchies, deferred sharing calculations, granular locking, and partner isolation at scale.
- If You’re Not Archiving Today…. Lifecycle on day one, backup before delete, where the archive lives, the three-step archive, and agents and old data.
What an architect decides here
Section titled “What an architect decides here”- How big each object gets, at growth and over its retention period.
- Where records concentrate, and which concentrations are dangerous.
- What ownership means for each high-volume object, including those agents create.
- How the access model scales, and how big realignments are planned.
- How data leaves: archive, purge, backup, and who can still find it.
Beyond the exam: agents add zeros. They can create ten records where a person created one, own them all by default, retrieve faster than anyone, and reach into archives unless someone decides they shouldn’t. Each module ends with what AI changes for its part of the problem.
Explore
Section titled “Explore”- Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (opens in a new tab), checked 2026-11-01.
- Salesforce Developers, Designing Record Access for Enterprise Scale (opens in a new tab) (Winter ‘27), checked 2026-11-01.
- Salesforce Developers, Best Practices for Deployments with Large Data Volumes (opens in a new tab) (Winter ‘27), checked 2026-11-01.