SF-Data-Arch Large Data Volume Considerations Practice Question
When dealing with high-frequency updates on a parent object, what is the best practice to prevent lock contention?
⚠ Common exam trap
Candidates often suggest using triggers for synchronous roll-ups, which causes massive row-locking issues when multiple child records are updated simultaneously in high-volume environments.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Use an asynchronous approach to aggregate parent updates.
To minimize lock contention, avoid updating the parent record every time a child record is updated. Instead, use an asynchronous pattern like a batch job or a queueable apex to aggregate updates and perform a single update to the parent. This reduces the number of locks requested on the parent object, significantly decreasing the likelihood of row-locking errors during high-volume operations.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Always update the parent in the child's trigger.
Why it's wrong here
Updating the parent in a trigger for every child record is the primary cause of row locking. Because each child trigger runs in its own context, multiple threads will simultaneously attempt to lock the same parent, leading to frequent contention and failures under high-concurrency or large-volume loads.
- ✓
Use an asynchronous approach to aggregate parent updates.
Why this is correct
Asynchronous processing allows updates to be queued and batched, preventing multiple concurrent transactions from fighting over the same parent row. This pattern is essential for high-frequency updates, as it serializes the parent-level changes and allows the system to process them efficiently without risking transactional row locks.
- ✗
Set the parent record to read-only.
Why it's wrong here
Setting a record to read-only is a security configuration, not a performance optimization. It would prevent legitimate updates to the parent, which is likely not the desired business outcome. It does not address the technical problem of row locking that occurs during legitimate high-volume data updates.
- ✗
Convert the lookup relationship to a master-detail.
Why it's wrong here
Master-detail relationships are more likely to cause row locking than lookup relationships because the system automatically enforces parent-level locking during child operations. Converting to master-detail would actually exacerbate the problem rather than resolve it, as it increases the coupling between the parent and child records.
About these practice questions
Courseiva writes every SF-Data-Arch question from scratch — 222 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Salesforce exam blueprint
This SF-Data-Arch practice question is part of Courseiva's free Salesforce certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SF-Data-Arch exam.