Design the integration around one requirement: repeated delivery of the same order-creation intent must resolve to the same business order. That requires a stable identity, an atomic decision at the destination, and a recovery process for uncertain outcomes.

Define what counts as the same operation

Give each order-creation intent a durable idempotency key before its first transmission. Persist that key with the originating record and reuse it across retries, worker restarts, and manual replays. A new random key on every attempt defeats deduplication.

Scope the identity explicitly. A useful conceptual key is tenant plus source system plus source order identifier plus operation type. Separate creation from amendment or cancellation. Do not use a customer's email address: one customer can legitimately place multiple orders.

Store a fingerprint of the relevant request data alongside the key. If the same key arrives with different quantities or currency, return a conflict rather than silently reusing an earlier result. Define normalization rules so irrelevant formatting changes do not create false conflicts. AWS describes this relationship between caller-provided identifiers and request intent in Making retries safe with idempotent APIs.

Make the destination decision atomic

When you control the receiving database, enforce a unique constraint on the scoped operation identity. A separate “does this exist?” query followed by an insert is insufficient: concurrent workers can both observe absence.

In one database transaction, claim the identity, create the order, and record the resulting order identifier. Commit them together. If the transaction rolls back, none of those changes should survive. A competing request must resolve through the uniqueness constraint and retrieve the committed result, or receive a documented retryable response while work is unfinished.

This recommendation assumes the order and deduplication record share a transaction boundary. A local integration database cannot atomically commit a remote ERP API call. For an external ERP, use its documented idempotency mechanism or a destination-enforced unique external reference. Without either, acknowledge that local locking alone cannot guarantee duplicate prevention after a crash.

Bridge database commits and message delivery

An outbox addresses another failure window: saving the source order succeeds, but publishing its message fails. Save the order change and an outgoing event in the same local database transaction. A separate dispatcher delivers committed outbox events and records delivery progress.

The dispatcher can still publish twice, for example if it crashes after publishing but before recording success. The receiving side therefore needs deduplication too. An inbox can record the event identifier and apply its local business changes within one transaction. Acknowledge the message after commit. These responsibilities are explained in AWS's transactional outbox guidance and the Idempotent Consumer pattern.

Keep event identity separate from order identity. Two different events can still request the same order creation. An inbox catches repeated events; the business-level constraint catches repeated intent.

Treat timeouts as unknown outcomes

After a timeout, label the attempt “outcome unknown,” not automatically “failed.” Query the destination by the stable external reference or retry using the original key under the destination's documented contract. Never generate a replacement key merely to get past uncertainty.

If the destination cannot reliably resolve that reference, pause automatic creation and route the case for reconciliation. A missing search result may reflect indexing delay rather than an absent order.

Use retries without creating a storm

For this design, define a bounded retry policy with capped exponential backoff and random jitter. Respect server-provided retry timing where supported. Set both an attempt limit and an overall elapsed-time budget, and avoid independent retry loops at every integration layer.

Classify responses according to the destination's contract. Validation errors generally need corrected data, while throttling or temporary unavailability may justify retrying. An ambiguous write still needs the same idempotency protections regardless of the delay between attempts.

Reconcile and test the recovery path

Run reconciliation using source identifiers, destination identifiers, operation keys, and states. Flag source orders without a confirmed destination mapping, duplicate external references, and attempts stuck in an unknown state. Record ownership and an audit trail for repairs; do not automatically delete apparent duplicates that may already have downstream activity.

Before release, verify:

• Concurrent copies create one order and resolve consistently.
• A lost response after commit does not create another order.
• Worker crashes and message redelivery preserve identity.
• Changed payloads under an existing key produce a clear conflict.
• Tenant boundaries prevent cross-customer collisions.
• Manual replay follows the same deduplication path as automatic retries.
• Retention covers the permitted retry and replay window; older replays require an explicit policy.

The practical goal is a recoverable order workflow whose behavior stays predictable when delivery repeats or acknowledgments disappear.

Prepared for AT Global Tech Private Limited with AI-assisted research and editorial preparation. This article presents general engineering guidance, not a client case study or a claim about a deployed product.