IntegrationIntermediaterestconcurrencyoptimistic-locking
Implement REST If-Unmodified-Since optimistic concurrency control
Real World Scenario
Two integration jobs update same Opportunity amount; second overwrites first without detecting stale read causing incorrect forecast.
Expected Answer
• GET returns LastModifiedDate; PATCH sends If-Unmodified-Since header
• 412 Precondition Failed when record changed since read
• Retry read-merge-write with business merge rules
• Alternative If-Match with ETag from SObject response header
• Document concurrency policy per integration consumer
• High contention fields serialize via middleware queue partition key
• Audit 412 rate indicating hot record design issue
Follow-Up Questions & Answers
Click to expand — each follow-up includes a direct, interview-ready answer
Direct answer: GET returns LastModifiedDate; PATCH sends If-Unmodified-Since header Also consider: 412 Precondition Failed when record changed since read In practice: Retry read-merge-write with business merge rules Balance speed of delivery with maintainability.
Architect Perspective
Optimistic concurrency prevents silent lost updates—essential for financial field integrations.