Back to portfolio

Workato and NetSuite: Idempotent Order Sync Replay Demo

A sync that works on a quiet day can still corrupt revenue records under load. A response is lost after NetSuite has already saved the order, the recipe retries, and a second sales order appears. Inject faults into ten fictional order events, replay the batch, and see what a stable key and a version check change.

Fictional data and a deterministic simulation. Customers, amounts and identifiers are invented, and faults come from a seeded generator so every run is reproducible. The model is illustrative: it shows mechanisms, not the measured behavior of any product or organization.

Receiver and recipe design

Stable external key (upsert)The sales order is keyed by the Salesforce order ID, so a repeated create becomes an update. Version checkAn update is applied only if its version is newer than the stored one. Dead-letter queueAn event that exhausts its retries is parked for replay instead of being dropped.

Retry policy How many times the recipe calls NetSuite again after a timeout.

Timeout rate per call Half of timeouts happen before NetSuite saves the order, half after, when the response is lost.

Out-of-order deliveryAmendments can arrive before the order they amend, or before an earlier amendment.

Fault pattern Each pattern places the faults on different events.

NetSuite sales orders after the sync

Salesforce order and expected stateSales orders in NetSuiteResult

Delivery log

Architecture applied

1. A stable key at the receiver

The sender cannot know whether a timed-out call was applied. Only the receiver can make a repeat harmless, by keying the sales order on the Salesforce order ID so a second create resolves to the same record.

2. Version fencing for ordering

Integration layers do not guarantee order. Carrying a monotonic version on every event, and refusing anything not newer than the stored one, makes late and early arrivals converge on the same final state.

3. Bounded retries and a dead-letter path

Retries are capped, failures are parked with their payload instead of dropped, and replay becomes a routine operation. Replay is only safe because the first two layers exist.

Impact

Without a stable key, every recovery action carries risk, so teams hesitate to replay after an incident and orders stay missing longer. With one, replay becomes the standard repair: run it again and the state converges, with no duplicate sales orders to reverse.

Retries and dead-letter queues look like reliability features, but on a non-idempotent receiver they multiply the problem. The design question is not how often to retry but whether a repeated message is harmless by construction.