Bỏ qua để đến nội dung

Part 2 Study Guide: Architecting at Scale

Nội dung này hiện chưa có sẵn bằng ngôn ngữ của bạn.

An open sketchbook on a drafting table at dawn, a building sketched on one page and a data model on the other, with a pencil, an eraser, a cup and a lamp.
Image generated with AI

The study guide for Part 2 of the Data Architect course: six chapters, from designing for scale to data security, and Checkpoint 2. Each chapter has its own study guide with the full checklist; this page puts them together by exam section.

About this study guide. It’s built only from this course’s own content and the published Salesforce exam guide’s list of objectives. It is never based on real exam questions, and it doesn’t claim to know what’s on the exam. If you’ve taken the exam, please don’t send me questions from it: the certification agreement forbids sharing them, and memorizing answers is the wrong way to become an architect anyway.

Part 1 taught you to see the data. Part 2 puts weight on it: volume, queries, integration, migration, transactions and security. It carries the two exam sections Part 1 left out, Large Data Volumes and Data Migration, and finishes the others. Work through it in this order:

  1. Finish each chapter, then tick off its own study guide.
  2. Come back here and check each exam section below. If a line doesn’t feel solid, follow it back to its chapter guide.
  3. Try Checkpoint 2’s challenge, then compare your design with my walkthrough.

The weights come from the published exam guide (checked 2026-10-29). Check the current version before you book: Salesforce revises it.

Large Data Volume Considerations (20% of the exam)

Section titled “Large Data Volume Considerations (20% of the exam)”

All of Part 2, except virtualization (Part 3).

  • LDV-1, a model that scales. Salesforce is built for transactions on structured data. Size for growth across the retention period and multiply the children; volume has shape; controlled denormalization; don’t make the CRM your warehouse. Chapter 7. Inside the engine: multitenant and metadata-driven; indexes and the three checks; the selectivity thresholds (a standard index: 30% of the first million records plus 15% beyond, capped at 1 million; a custom index: 10% plus 5%, capped at 333,333); the Query Plan; two-column indexes; skinny tables; divisions; database statistics; index, rewrite, redesign or archive; SOSL, its limits and search crowding. Chapter 8. Integration volume becomes data volume: singles, sets and bulk, and more than 2,000 records is a candidate for Bulk API 2.0. Chapter 9.
  • LDV-2, archiving and purging. Retention, archiving and purging kept apart and decided on day one; backups before anything is deleted; purging at volume (the Recycle Bin’s 15 days, Bulk API 2.0 hard delete, children first); the archive destinations, big objects (object and field permissions only, no sharing rules), an external store through Salesforce Connect, or Salesforce’s Archive; the three-step archive; archives that stay findable and secure. Chapter 7. Getting data out at volume: the Data Export Service and PK chunking. Chapter 10.
  • LDV-3, virtualized data: Part 3, chapter 14, Virtualization, Federation, and Zero-Copy.

All of Part 2.

  • MIG-1, high data quality at load time. Migrate, archive or discard; a preparation data store; standardize, clean, enrich, dedupe, validate; legacy keys in External IDs, parents before children; a survivor chosen field by field and a plan for the merged record’s children; a quarantine with the reason; four proofs: counts, totals, spot checks and aggregate reports. Chapter 10. Reconcile counts and control totals, because “no errors” isn’t completeness. Chapter 9.
  • MIG-2, loading large volumes. Bulk API 2.0 against Bulk API 1.0 and serial mode; insert, then update, then upsert; sort by parent; keep each job’s results (seven days) and bring the new IDs back; for each automation, don’t need it, simulate it, defer it or let it run, with a bypass built in from the start; deferred sharing calculations; the cutover hidden by sharing; locking users out without deactivating them. Chapter 10. Keys, upsert and proof of delivery. Chapter 9. A timeout means the outcome is unknown; upsert on a unique External ID; an operation’s own key when it can legitimately repeat; retry transient failures with backoff, never validation errors. Chapter 11.
  • MIG-3, exporting data. The Data Export Service, Data Loader and reports, bulk query and backup products; PK chunking for tables over about 10 million records; a watermark on SystemModstamp, deletes with queryAll inside the Recycle Bin’s 15 days; migration ends, synchronization goes on, and the mirror is never the master. Chapter 10.

Data Modeling and Database Design (the Part 2 pieces)

Section titled “Data Modeling and Database Design (the Part 2 pieces)”
  • DM-5, data skew. Parent-child skew and the 10,000-children threshold, Controlled by Parent, account pools; master-detail at volume; ownership skew (one owner with more than 10,000 records of an object) and its fixes; lookup skew. Chapter 7. Record locking: optimistic and pessimistic; the 10-second wait; the lock footprint of a save; roll-ups that save the parent; deadlocks and locking order; group work by parent, and fewer parallel workers when transactions share a lock. Chapter 11. Account data skew spread across a child account per real business unit. Chapter 12.
  • DM-2, a data model that respects the security and sharing model. Sharing is data too: the share object, deferred sharing calculations, granular locking. Chapter 7. Page layouts don’t secure a field, field-level security does; splitting fields into their own object; Controlled by Parent and implicit sharing; org-wide defaults and the role hierarchy; sharing-rule types and limits; restriction rules; the external licenses and sharing sets; one integration, one user. Chapter 12. Every license side by side: Experience Cloud Licenses and Internal User Licenses.

Salesforce Data Management and Data Governance (the Part 2 pieces)

Section titled “Salesforce Data Management and Data Governance (the Part 2 pieces)”
  • SDM-4, several orgs. Two orgs are two systems, so a record ID from one isn’t an enterprise key in the other; one External ID per system; a contract for every movement, and sometimes the contract says don’t move it. Chapter 9. Connecting orgs without moving the data comes in Part 3.
  • GOV-1, protecting sensitive data. Classification fields are labels, not locks; the protection matrix; Shield Platform Encryption, field-level and Database Encryption; probabilistic by default, deterministic when the use requires it; masking outside production; data minimization and storage limitation. Chapter 12.

Who an agent runs as, instructions that guide but don’t enforce, mandatory approvals in a Flow checkpoint, and every prompt treated like SQL injection. Chapter 12.

  • Steve’s Number of Zeros, and the shape behind the zeros: where records concentrate, how they’re queried, how often they change.
  • What works today may fail tomorrow. A query can become bad without the query changing.
  • Design the exit when you design the entrance. Every high-volume object needs a lifecycle.
  • Zoom out, then zoom in. The landscape first, then one arrow at a time.
  • Know the record, know the owner. Keys and write authority make integrations, retries and migrations safe.
  • Proof of delivery: whoever knows what should arrive proves that it did, and a timeout means you don’t know yet.
  • Migration is a quality project first; synchronization keeps you there.
  • Find where the lock footprints overlap before tuning or retrying.
  • Security is decided in the data model. A prompt is not a permission set; treat an agent like a curious human.
  • Trust but verify, at the volume and distribution you’re designing for.

Two thirds of the way. Here’s the whole exam, and where each part of it is taught:

Exam section (weight)Part 1Part 2 (this part)Part 3 (coming)
Data Modeling and Database Design (25%)DM-1, DM-3, DM-4, start of DM-2DM-2, DM-5—
Salesforce Data Management (25%)SDM-1, SDM-2, start of SDM-3SDM-4: moving data between orgsSDM-3 and SDM-4: a single view across systems, and connecting orgs without moving the data
Large Data Volume Considerations (20%)—LDV-1, LDV-2LDV-3: virtualized data
Data Migration (15%)—MIG-1, MIG-2, MIG-3—
Data Governance (10%)GOV-2, start of GOV-1GOV-1—
Master Data Management (5%)MDM-1 to MDM-4——

After Parts 1 and 2, every objective on the exam is covered except virtualized data (LDV-3), and two are only partly covered: SDM-3, a single view of the customer across systems, and SDM-4, connecting several orgs without moving the data. Those come in Part 3, which is being written now. Until it’s out, study them from the exam guide (opens in a new tab) and Salesforce’s own documentation. Part 1’s sections are in the Part 1 study guide (coming soon).

Each chapter’s study guide has its own Check Yourself questions. For Part 2 as a whole, the test is Checkpoint 2: take the Part 1 Steve Trucking design to year five, three times today’s volume, with three partner integrations, archiving, and security for partners, crews, Recipients and agents. Try the challenge, then compare your reasoning with my walkthrough.

The chapter study guides:

  1. Designing for Scale
  2. Query and Retrieval Architecture
  3. Integration and Data Movement
  4. Migration and Synchronization
  5. Transactions, Concurrency, and Reliability
  6. Data Security for Humans, Applications, and Agents