Study guide

Image generated with AI

Study guide for chapter 11 of the Data Architect course. Read the three modules first; this page helps you check what stuck.

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.

The exam touches this chapter through data skew and record locking (part of Data Modeling), and through loading at volume. Contention design and safe retries go well beyond the exam, and they’re where real systems fail at 4 p.m.

For the Exam

Tick them off as you go. Each one links to where it’s taught.

DM-5: record locking and skew

• I can explain optimistic and pessimistic locking, and that Salesforce is both: optimistic across a user’s edit session (collision detection at save), pessimistic inside the transaction. (Two Ways to Lock)
• I know a save locks the records it changes and related records, held until the transaction completes, and that another transaction waits up to 10 seconds for a lock, then fails (UNABLE_TO_LOCK_ROW). (Two Ways to Lock)
• I know FOR UPDATE locks queried records for the rest of the transaction, can’t be used with ORDER BY, and loses its locks if the transaction makes a callout; and that locked records can still be read. (Two Ways to Lock)
• I can draw the lock footprint of a save: the record, the parents it looks up to, a roll-up’s parent, and the records automation touches. (Draw the Footprint of One Save)
• I know a lookup locks the record it points to when a child is inserted or updated, so lookups can cause contention too (lookup skew). (Relationships Change the Footprint)
• I know a roll-up summary makes the child’s save update the parent, and the parent then goes through its own save (and the grandparent’s roll-up), inside the same transaction. (Relationships Change the Footprint)
• I know why a crowded parent hurts at peak: different children, one shared lock, one at a time. (One Intersection)
• I know what a deadlock is, that Salesforce locks parents before children and in ID order, and that my code should lock in the same order everywhere. (Two Trucks Stuck in the Intersection)
• I know that DML on setup objects (such as User) can’t be mixed with ordinary records in one transaction. (Draw the Transaction Before You Tune It)
• I know the ways to reduce lock contention: relieve the shared parent (distribute children, avoid roll-ups on busy parents, or move to a lookup with counts calculated later). (Lever 1)
• I know moving work to asynchronous processing shortens the transaction but brings eventual consistency. (Lever 2)
• I know to group work by parent: sort loads by parent ID, and give platform event triggers a partition key that keeps events for the same record together. (Lever 3)
• I know fewer parallel workers, or serial mode, can finish more work when transactions share a lock. (Lever 4)

Reliability (supports MIG-2 and every integration in a scenario)

• I know a timeout means the outcome is unknown, not that the request failed. (Failure and Uncertainty Are Different)
• I know upsert on a unique External ID makes a resent record update instead of duplicating. (The Business Operation Needs an Identity)
• I know when an operation needs its own key (one that can legitimately repeat, such as a credit), and that the key stays the same on every retry. (The Business Operation Needs an Identity, Retry the Same Intent)
• I know which failures to retry: transient ones (locks, timeouts, server errors) with backoff; rate limits after the wait the server gives; never validation errors until they’re fixed. (Which Failures to Retry, and How)
• I know a subscriber can replay high-volume platform events from the last 72 hours, and that new custom platform events are high volume by default. (Eventually, Automatic Retry Must Stop)

Beyond the Exam

The exam is the floor, not the ceiling. These are the habits from this chapter that an architect needs, whether or not a question ever asks about them.

• One save is rarely just one record. Draw the footprint before you tune anything.
• One user usually hides the problem. Concurrency reveals it: it works today and fails tomorrow.
• A lookup still locks. What a roll-up adds is more work while the lock is held.
• Different records, one intersection. Find where the footprints overlap.
• Observe before you guess, then check the drawing against what production says.
• Work the four levers first; retry is for what still fails.
• More workers aren’t more capacity when they all need the same lock.
• Serialize only the work that competes: one line per parent, the lines side by side.
• Asynchronous isn’t eventually correct by magic. Measure how far behind it runs.
• Use FOR UPDATE deliberately, typically on one record, and get out quickly.
• A lock protects the transaction; it can’t define the truth.
• If the client owns the retry, the architecture must make the retry safe.
• Recount; don’t add one. An update that can run twice must give the same answer.
• “Exactly once” is a dangerous phrase. Design for effectively once.
• Automatic retry must stop, and the work must go somewhere visible.
• Give agents established, tested actions with focused scope and safe retries.

Words to Know

Term	In one line
Lock	Temporary control of a record so another transaction can’t make a conflicting change
Lost update	Two writes based on the same old value, so the second silently erases the first
Optimistic locking	No lock while working; a conflict is detected at save
Pessimistic locking	Lock first, then change, then release
Collision detection	Salesforce’s check at save that someone else changed the record during your edit
Lock footprint	Every record a save must protect until it commits
UNABLE_TO_LOCK_ROW	The error when a transaction waits too long for a lock
Lookup skew	Very many records looking up to the same record, so their saves compete for its lock
Deadlock	Two transactions each waiting for a lock the other holds
Mixed DML	Changing setup objects and ordinary records in one transaction, which isn’t allowed
Contention domain	The smallest set of work that actually competes for the same lock
Partition key	The field that decides which parallel subscription handles a platform event
Idempotency	Repeating a request without performing the business action twice
Record identity	Which record this is: a key such as an External ID
Operation identity	Which business action this is: a key for an action that can legitimately repeat
Backoff	Waiting, and waiting longer, before retrying
Jitter	A little randomness in the wait, so failed workers don’t retry together
Retry storm	Many failed requests retrying at once and making the problem worse

Check Yourself

Short scenarios in the style of the course. Decide your answer before you open it.

1. A developer says, "Salesforce uses optimistic locking, so we don't have to worry about locks." What's right and what's missing?

Right for the user’s edit session: nothing is locked while the edit screen is open, and a conflict is caught at save. Missing: inside the save, Salesforce locks the changed records and related records until the transaction completes, and a waiting transaction fails after 10 seconds. Reread Two Ways to Lock.

2. "It's only a lookup, so the parent isn't involved." True?

No. Salesforce locks the record a lookup points to when a child is inserted or updated. What a master-detail roll-up adds is the parent’s own save inside the child’s, so the lock is held longer. Reread Relationships Change the Footprint.

3. At 4 p.m., hundreds of crews' saves fail with UNABLE_TO_LOCK_ROW. Each one is a different Work Order. Where do you look?

At what they share: the Manifest every Work Order points at, and whatever each save does to it. Find where the footprints overlap, then check it against what production shows. Reread Find the Shared Lock.

4. Two processes each update an Account and a Manifest, in opposite orders, and sometimes both fail. What's happening, and the fix?

A deadlock: each holds the record the other needs. Lock in the same order everywhere, parents before children, as Salesforce’s own engine does. Reread Two Trucks Stuck in the Intersection.

5. The team proposes recalculating the Manifest's counts in a nightly batch to stop the lock errors. The coordinators object. Who's right?

The coordinators: they need the counts accurate within seconds, not hours. Keep the counting out of the crews’ saves, but run it close behind, for example with a platform event trigger that recounts each Manifest in batches. Reread Lever 2.

6. Status updates collide within each Manifest but never between Manifests. Turn off parallel processing?

No. Serialize per Manifest and let different Manifests run side by side. With platform event triggers, make the Manifest’s ID the partition key. Reread Lever 3.

7. A request to credit a partner $180 times out, and the integration retries. What can go wrong, and how do you design it?

The first request may have succeeded, so the retry credits twice. Give the credit its own key, the claim number, sent unchanged on every retry, so the receiver recognizes it and returns the first answer. Reread The Business Operation Needs an Identity.

8. Every resent manifest line creates a second Work Order. What's missing?

Record identity: upsert on a unique External ID (the partner’s order number), so a resend updates the Work Order it already created. Reread The Business Operation Needs an Identity.

9. A platform event trigger adds one to the Manifest's delivered count for every event. Sometimes the count is too high. Why, and the fix?

Events can be processed more than once, for example when a batch is retried. Make the update idempotent: recount the Manifest’s Work Orders and write the total. Reread Updates Can Be Idempotent Too.

10. A hundred workers fail on the same locked record and all retry at once. What happens, and what's better?

A retry storm: the same traffic goes straight back into the same jam. Retry transient errors with backoff and jitter, under a limit, then stop and alert. Reread Retry Doesn’t Mean Retry Immediately.

11. The request fails with a validation error: the claim number is missing. Retry with backoff?

No. It will fail the same way every time. Park it, fix the data, then replay it. Reread Which Failures to Retry, and How.

12. An agent will issue partner credits. What do you give it?

An established, tested action (“Issue Partner Credit”) that owns its key, validation, retries and write scope, not broad access to the records. Reread Agents Have the Same Unknown Outcome Problem.

Explore

• Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (checked 2026-11-01): the official list of objectives and their weights. Always check the current version before you book the exam.
• Each module’s own Explore section lists the Salesforce documentation behind its facts, with the date checked.