IntegrationAdvancedplatform-eventsidempotencydeduplication
Handle duplicate Platform Event delivery in event-driven subscribers
Real World Scenario
Payment-completed Platform Event processed twice creates duplicate shipment orders in warehouse system.
Expected Answer
• Event UUID or business key stored with unique constraint Processed_Event__c
• Subscriber checks processed table before side effects
• At-least-once delivery assumption in all event designs
• Idempotent warehouse API accepts duplicate order id same response
• Replay ID tracking detecting true duplicates vs replays
• TTL on dedup table preventing unbounded growth
• Test duplicate delivery explicitly in integration tests
Follow-Up Questions & Answers
Click to expand — each follow-up includes a direct, interview-ready answer
Direct answer: Event UUID or business key stored with unique constraint Processed_Event__c Also consider: Subscriber checks processed table before side effects In practice: At-least-once delivery assumption in all event designs Optimize for scale and operational observability.
Architect Perspective
Platform Events guarantee delivery not uniqueness—dedup layer is subscriber responsibility.