IntegrationAdvancedidempotencypaymentsreliability
Implement idempotent integration patterns for financial transactions
Real World Scenario
Payment confirmation webhook retries caused duplicate Payment__c records and double revenue recognition.
Expected Answer
• Idempotency-Key header or external transaction ID with unique constraint in Salesforce
• Upsert on external ID returning same response for duplicate requests
• Store raw webhook payload hash detecting duplicate deliveries
• Middleware deduplication window before Salesforce call
• Compensating transactions for rare duplicate detection post-commit
• Audit log linking external ID to Salesforce record ID
• Test retry storms simulating 5x duplicate delivery
Follow-Up Questions & Answers
Click to expand — each follow-up includes a direct, interview-ready answer
Direct answer: Idempotency-Key header or external transaction ID with unique constraint in Salesforce Also consider: Upsert on external ID returning same response for duplicate requests In practice: Store raw webhook payload hash detecting duplicate deliveries Optimize for scale and operational observability.
Architect Perspective
Assume every message arrives twice—idempotency keys are integration hygiene not optional.