Skip to content

Synchronization Job

Propagation automation — instantiates Source-of-Truth Assignment

Propagates authoritative values from the source into every dependent system on a schedule or on change, and records the lag, transformations, and failures so downstream copies are known to be aligned — or known to be behind.

Synchronization Job is the runtime propagation that carries the authoritative value outward to every system that holds a copy. It decides nothing about what is true; it distributes the truth and, just as importantly, measures how far each downstream copy has drifted. Its distinguishing contribution is that pairing — push the authoritative value on a schedule or on change, and emit a reconciliation report of what synced, what lagged, and what failed — so a stale copy is known to be stale rather than silently wrong.

Example

A retailer's pricing system of record sets prices; those prices must reach POS terminals in 400 stores and the public website. A synchronization job propagates each price change downstream — near-real-time to the website, in a nightly batch to stores whose connectivity is intermittent — applying any currency and rounding transformation on the way. Critically, it records which stores acknowledged the update, which lagged, and any transform applied. When store 214 misses the sync, its reconciliation report flags the store as stale instead of letting it quietly sell yesterday's price. Downstream systems converge on the authoritative price, and the ones that have not converged are visible — which is the whole point of eventual consistency done honestly.

How it works

On a schedule or on change, the job reads the authoritative value, transforms it as needed for each dependent, writes it downstream, and records the outcome — acknowledgement, lag, or failure. Its two defining pieces are the synchronization logic (cadence, direction, transformation) and the reconciliation report of downstream drift. It embodies eventual consistency: copies converge over time rather than instantly, so the job's job is as much to surface the gaps as to close them. It executes the sync policy; it does not set that policy or decide the source.

Tuning parameters

  • Sync cadence — real-time/on-change versus batch. Faster propagation shrinks the stale window but costs load and complexity.
  • Push versus pull — the source pushes to dependents, or dependents pull on read. Push converges eagerly; pull keeps reads fresh but shifts the work to read time.
  • Conflict-on-write handling — overwrite the downstream copy unconditionally, or detect when a dependent has changed locally and hold rather than clobber.
  • Lag tolerance — how far behind a dependent may fall before it is flagged stale and alerted on. Tight tolerance catches drift early but is noisier.

When it helps, and when it misleads

Its strength is keeping a fleet of copies aligned to the source and — crucially — making the unaligned ones visible instead of silently wrong. Its failure modes are quiet drift and in-flight corruption: a sync that fails without anyone noticing, so a dependent falls behind unseen, or a transformation that mangles the value on the way down. The classic misuse is treating "synced" as "consistent" when the system is only eventually consistent[1] and a reader has just hit a copy that is momentarily behind. The discipline that guards against this is monitoring lag and reconciling actively — never assuming propagation succeeded, and treating the reconciliation report as a live signal rather than a log nobody reads.

How it implements the components

  • synchronization_rule — the propagation logic that carries authoritative values downstream: cadence, direction, and transformation per dependent.
  • reconciliation_report — the record of lag, transformation, and failure that tells you which downstream copies are aligned and which are behind.

It does not decide which value is authoritative in the first place (that is System-of-Record Designation), set the enterprise-wide sync policy it executes (that is Master Data Management), or preserve the source's own change history (that is Change Log and Audit Trail).

  • Instantiates: Source-of-Truth Assignment — it is the runtime that keeps the many copies aligned to the assigned source and reports where they are not.
  • Consumes: System-of-Record Designation supplies the authoritative source the job propagates; Master Data Management sets the sync policy it runs.
  • Sibling mechanisms: Master Data Management · System-of-Record Designation · Golden Record Consolidation · Canonical Registry · Conflict Resolution Workflow · Change Log and Audit Trail · Access and Update Rights Matrix · Official Record Policy · Authoritative Policy Repository · Deprecation and Forwarding Notice · Source-Control Main Branch

Notes

Its reconciliation_report overlaps Golden Record Consolidation's by name only: consolidation reports which conflicting fields were merged into one record; this job reports which downstream systems are behind the source. One reconciles duplicates into a master; the other reconciles copies against a master.

References

[1] "Eventual consistency" — the guarantee that, absent new updates, all copies of a value will converge to the same state, though at any instant some may be stale. A synchronization job is the machinery of eventual consistency; its reconciliation report is what keeps "eventually" from becoming "unknowably." ↩