A delivered update can still move the record backward
A university changes the room for an evening course. The scheduling system saves revision 42, and the website shows the corrected location. A delayed message carrying revision 41 arrives afterward. The integration accepts it, replaces the room, and reports success.
Every message arrived. The public page is wrong.
This hypothetical example matters for higher-education teams connecting academic and administrative systems. A schedule, program listing, or registration status can pass through several systems before someone relies on it. Arrival time alone does not establish which information should win.
The release question is straightforward: can an older update undo a newer correction? Answer it before a queue backlog, retry, or historical import makes the decision for you.
Name the source that owns each value
Start with the business record and the fields being synchronized. In the course example, the scheduling system owns room, meeting time, and cancellation status. The CMS owns the public description and supporting links. A schedule update should not overwrite the editor's description simply because both appear on the same page.
Record three identities:
- The source record: a stable identifier for this course offering, including the source system and any required term or tenant scope.
- The source revision: a value whose documented rules let the receiver determine which state is newer for that record.
- The delivery: an identifier used to recognize repeated messages and investigate transport failures.
These serve different purposes. Two distinct deliveries may carry the same revision. A unique delivery can still contain an obsolete revision. Reusing a course code next term may represent a different offering entirely.
Put those meanings into the integration contract reviewed with each release. Specify which fields the source controls, what advances its revision, and whether the payload contains a complete state or only a change. A schema version describes the payload's format; it does not tell you which course update is newer.
Avoid treating timestamps as an automatic ordering guarantee. Clocks can differ, precision can collapse separate changes into the same instant, and an export time may describe when a file was generated rather than when a record changed. Use a source-provided sequence only within the scope and guarantees that source documents.
Separate delivery order from business order
Delayed and reordered messages are an expected design case for many integrations. Stripe's webhook documentation, for example, explicitly says events need not arrive in generation order. That is a provider-specific guarantee to check, not a reason to assume every connector behaves identically.
For the hypothetical schedule integration, suppose the source provides an increasing revision for each offering and every message contains all source-owned schedule fields. The receiving record already holds revision 42:
- Revision 41 is older. Record its arrival without replacing the schedule.
- Revision 42 with the same contents is already represented. Avoid repeating its business effects.
- Revision 43 is a candidate update. Validate it and apply it through the controlled write path.
- Revision 42 with different contents violates the agreed contract. Hold it for investigation rather than choose whichever copy arrived last.
The retry controls that prevent duplicate business work remain necessary. They answer whether an action has already happened. Revision checks answer whether incoming state may replace what is there now.
Complete snapshots and incremental changes need different rules
A complete revision 43 can supersede revision 41 for the fields it fully represents, even if revision 42 never arrived. A message saying “increase capacity by five” cannot safely be treated the same way. Skipping a prior increment changes the result.
For incremental changes, define how missing steps are detected and recovered, or rebuild the current state from an authoritative source. Do not discard every older message indiscriminately: some events record obligations or actions that remain relevant even after the displayed state changes. Keep rebuilding a current view separate from deciding which business actions must occur.
Enforce the decision when the write commits
A revision check in application code can still lose a race.
Two workers both read revision 40. One receives 41; the other receives 42. Both decide their update is newer. If 42 writes first and 41 writes afterward without a database condition, the record moves backward despite both checks passing.
The comparison and update need one atomic boundary. Use the destination's conditional-write or transaction capabilities so an update succeeds only while the stored state satisfies the expected condition. Save the source revision with the fields it describes. If another worker wins first, reread and evaluate the incoming update again.
AWS's optimistic-locking documentation illustrates rejecting a write when the stored version changed after it was read. The destination's concurrency version and the source's business revision have different jobs; the implementation needs to preserve both meanings. Check the actual database and replication behavior rather than assume one SDK feature covers every deployment.
If the destination cannot enforce a conditional update, consider a controlled writer that serializes changes per record and preserves that ownership during failures. Serialization alone does not establish freshness: the writer still needs a trustworthy source revision or a documented reconciliation process.
Some sources provide neither ordered revisions nor usable snapshots. Make that limitation visible. Hold ambiguous updates for review or reconcile through the source's supported interface; a newly fetched response is not proof of freshness unless the source's consistency guarantees support that conclusion.
Recover current state without reviving old work
Reconciliation compares the receiving system with its authoritative source and repairs differences under the same ownership and revision rules. Give it a bounded scope, a responsible operator, and a record of the decisions it made.
For the course example, show the source offering, incoming revision, stored revision, affected fields, and reason an update was held or skipped. Distinguish an old update safely ignored from a newer update that could not be applied. Track the age of unresolved current-state gaps as well as delivery errors.
Cancellation and deletion need the same protection. If deleting a local record also erases all revision history, a delayed earlier update may recreate it. Retain the minimal identity and revision information needed to recognize retired records for the supported replay window, subject to the organization's retention rules. Define what happens beyond that window before allowing historical imports.
An intentional rollback is a new business decision. If an authorized scheduler restores a previous room, the source should issue a new revision with that value. Replaying revision 41 to overwrite 42 would make an old delivery indistinguishable from a deliberate correction.
Keep notifications and other side effects under their own controls during repair. Restoring the latest schedule should not automatically resend every historical room-change email. Decide which communication is needed now and record it as a distinct action.
Prove that corrections survive the next release
Use controlled records to test the sequence people usually miss:
- Apply revision 42, then deliver 41. Confirm 42 remains visible in the destination and public page.
- Process 41 and 42 concurrently. Confirm the final state is 42 regardless of which worker finishes first.
- Deliver a repeated revision and a conflicting copy. Confirm each follows its defined path without duplicate effects.
- Cancel an offering, then replay an older active snapshot. Confirm it stays canceled.
- Reconcile a missing update. Confirm the current schedule is repaired without replaying obsolete notifications.
For a source that sends incremental changes, add a missing-step test and prove how the system restores the complete result. Inspect the destination and the user-facing view, including any relevant cache; a successful worker response is only one checkpoint.
Reliable systems integration preserves the meaning of a correction as data moves between tools. Begin with one important record, name its authoritative fields, establish how newer state is recognized, and make the write enforce that rule. Then recovery can restore progress without quietly reversing it.
If your connected systems sometimes disagree after a release or replay, Start a Project to define the ownership, update rules, and recovery checks around one critical handoff.
