Oracle Integration Cloud: Building Integrations That Survive Production · Module 9 · Idempotency and duplicate prevention
Where to enforce it
Lesson 96 of 175 · 2 min
A UNIQUENESS CONSTRAINT IN THE TARGET BEATS A CHECK IN THE FLOW. That sentence is the design decision, and the reason is a race. CHECK-THEN-WRITE is what everybody builds first: look for the key, and create it if it is not there. It works perfectly in testing and it is a race in production. Two runs execute the check at the same moment, both find nothing, and both create — because between the check and the write there is a gap, and concurrency lives in gaps. TWO CONCURRENT RUNS WILL FIND IT. Not might: a scheduled flow that overlaps itself, a partner sending twice, a resubmission alongside a retry. The window is small and the number of attempts over a year is large, and that is all a race needs. A CONSTRAINT IN THE TARGET HAS NO GAP. The second write is refused by the database or the application, atomically,…
The full lesson is part of the course
The video, the complete written lesson and the module quiz are included in Oracle Integration Cloud: Building Integrations That Survive Production, with a certificate on completion and a fourteen-day refund window.
In this module: Module 9 · Idempotency and duplicate prevention
- 1Why every integration is retriedFree preview
- 2What idempotency means here
- 3Choosing a correlation key
- 4Where to enforce it
- 5When the target has no natural key
- 6Timeouts: the ambiguous outcome
- 7Idempotency across a whole file
- 8What breaks: three duplicate scenarios
- 9Lab briefing · Make a payment flow safe to retry