Orders change after creation. Payments settle, fulfillment advances, refunds arrive, and users export overlapping date ranges. A synchronization process that assumes every record is new will eventually duplicate data or fail when the same order appears twice.

Replay is normal, not exceptional.

We design imports around stable business identities. An order has one identity even when it contains many lines, appears in several exports, or is processed again after an interruption.

For batch imports, the safest pattern is often to stage and validate the complete extract, identify the affected orders, and replace those orders transactionally. For API replication, a bounded overlap window lets recent changes be re-read and reconciled without rebuilding all history.

Design principle

If running the same valid input twice changes the result twice, the integration is not finished.

Headers and lines require different thinking.

A subtle failure mode appears when one order contains multiple product rows. Treating every row as a new order header creates duplicates; collapsing every order to one row loses the products.

We preserve the hierarchy: one order header, many line records, and controlled replacement of the complete order aggregate. That makes totals explainable and keeps downstream joins stable.

A dependable synchronization includes

  • Stable source identities for orders and lines.
  • Staging validation before production changes.
  • A transaction boundary around replacement.
  • Overlap or checkpoint logic for late updates.
  • Exact or bounded reconciliation against the source.
  • Locks and timeouts that prevent overlapping workers.

Reconciliation is part of the product.

A green process log only proves that code finished. It does not prove that the destination matches the source. We add comparisons that answer a business question: are the expected order headers present for the same bounded period, and can any difference be isolated?

When mismatches remain, the audit should say so clearly rather than convert a near-perfect percentage into a claim of completeness. Precision builds operational trust.

Reusable pattern: stable identity, hierarchical persistence, bounded replay, transactional replacement, and source-level reconciliation.