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.
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.
Review a repeated run as carefully as a first run
A useful synchronization check asks what happens when the same order arrives twice, when a line changes, or when a run stops between reading and writing. These are ordinary integration situations, not unusual edge cases that can be ignored after the first successful transfer.
Stable order and line identities give the process a way to recognize existing records. Staging and validating the complete batch before replacement protects the relationship between the order header and its lines. The transaction boundary matters because a partly updated order can be harder to detect than a clearly failed request.
Bounded overlap in API retrieval helps revisit recent changes, while reconciliation checks whether the stored result still agrees with the source. Locks and timeouts address execution control rather than replacing those data checks.
The aim is repeatable recovery with understandable boundaries. It is not a claim that failures disappear. A dependable integration makes another attempt safe and leaves enough information to explain what was accepted, changed, or still needs attention.
Reusable pattern: stable identity, hierarchical persistence, bounded replay, transactional replacement, and source-level reconciliation.