Enterprise data synchronization keeps the right version of a record aligned across the systems that need it. The difficult part is not moving fields from one application to another. It is deciding which system owns each field, how records are matched, when changes move, which update wins, how failed writes recover, and how the team verifies the destination state. A reliable design treats synchronization as a governed operating process, not a collection of connectors.
That distinction becomes urgent in Commerce and Retail. Product, price, inventory, supplier, order, and customer data change on different clocks. They also have different owners. A product description may belong to the PIM, cost to the ERP, inventory to a warehouse system, and channel status to a marketplace. Copying every update everywhere without an ownership model creates faster confusion.
What enterprise data synchronization means
Data synchronization is the controlled propagation of selected changes between systems so each destination has the state it needs for its job. The systems do not have to contain identical records. They need agreed identities, field ownership, transformation rules, timing, and recovery behavior.
Synchronization can run in several ways:
- One-way sync moves approved changes from an authoritative source to one or more destinations.
- Two-way sync allows changes to travel in both directions, which makes conflict policy and loop prevention mandatory.
- Batch sync processes changes on a schedule.
- Event-driven sync reacts to a business event, webhook, message, or change record.
- Change data capture records inserts, updates, and deletes from a source and propagates those incremental changes. Google Cloud describes CDC as a way to track source changes and keep other systems synchronized without repeatedly extracting the full dataset.
These are transport patterns, not governance models. A real-time webhook can still copy the wrong value. A nightly batch can be correct for a low-volatility field. Start with the business rule, then choose the transport.
Why point-to-point sync breaks down
A direct connection between two systems can be sensible. An ERP sends inventory to an ecommerce platform. A CRM sends an approved audience to an email tool. The trouble starts when every new system adds another private mapping, identifier rule, retry policy, and definition of truth.
The same product then carries several IDs. The CRM calls a company an account, billing calls it a customer, and support calls it an organization. A field changes in two places before either update completes. One connector retries after a timeout and creates a duplicate. Another fails silently because a destination added a required field.
The result is not just integration sprawl. The business loses the ability to answer basic operational questions:
- Which system owns this value?
- Which change happened first?
- Was the destination updated?
- Did a retry repeat the write?
- Which records are waiting for review?
- Can the team replay the failed work without overwriting a newer decision?
Adding another connector does not answer those questions. The synchronization design has to own them.
Seven decisions every synchronization flow needs
The following model is a Boost.space editorial framework. It is meant for architecture workshops and pilot reviews, not as a formal industry standard.
1. Assign authority by field and decision
"The ERP is the source of truth" is usually too broad. An ERP may own cost, tax class, and stock position while a PIM owns product copy and taxonomy. A commerce platform may own channel merchandising, but it should not overwrite the approved product identifier.
Document authority at the smallest useful level:
- record type;
- stable identifier;
- field or field group;
- source system;
- permitted writers;
- approval rule;
- destinations;
- freshness requirement.
This prevents a central data layer from becoming a second, accidental master for every field. The layer can unify identities and current operational context without stealing ownership from the systems designed to make each business decision.
2. Resolve identity before copying attributes
Synchronization cannot be trusted if the same real-world entity appears under unrelated IDs. Match records using stable keys and retain the remote IDs used by each system. Do not depend on names, titles, or mutable email addresses when a durable product, customer, order, or supplier key exists.
For Commerce data, identity design often needs to distinguish:
- product, parent product, and variant;
- internal SKU, supplier SKU, GTIN, and marketplace listing ID;
- customer, account, contact, and household;
- order, shipment, return, and refund.
A mapping that works for the happy path can still merge two variants or split one customer into several records. Test ambiguous and missing-key cases before enabling automatic writes.
3. Define how changes are detected
Polling, webhooks, event streams, and CDC have different trade-offs. The right choice depends on the source API, expected volume, acceptable delay, ordering requirements, and ability to recover.
CDC is useful when a database change log is available and the goal is to move incremental inserts, updates, and deletes. Google Cloud's current CDC overview distinguishes log-based, trigger-based, and timestamp-based approaches, each with different source-load and latency characteristics. SaaS synchronization often relies on APIs and webhooks instead.
Record a cursor, version, event ID, timestamp, or equivalent checkpoint so the process knows where to resume. "Run again from the beginning" is not a recovery strategy for a large, changing catalog.
4. Choose direction and acceptable delay
Not every field needs real-time two-way sync. Price and availability may need short propagation windows. Product descriptions may follow an approval workflow. Historical reporting data may be intentionally delayed.
For every path, specify:
- one-way or two-way direction;
- trigger or schedule;
- maximum acceptable staleness;
- ordering requirement;
- behavior during a source or destination outage.
Two-way synchronization should be reserved for fields that genuinely need more than one permitted writer. It increases the risk of loops, stale overwrites, and conflicting edits. If one system can own the decision, a one-way path is simpler to operate.
5. Make transformation and validation explicit
A sync flow often changes more than field names. It may convert units, map categories, normalize currencies, split addresses, translate controlled values, or apply market rules.
Keep those decisions in a versioned mapping contract. For each field, define the source, destination, transformation, accepted values, validation, and failure behavior. Store the original source value alongside the normalized result when provenance matters.
This is especially important for supplier catalogs. The supplier catalog automation workflow shows the business context: supplier files arrive in different formats and schemas, while ERP, ecommerce, marketplace, and PIM destinations expect consistent product records.
6. Set conflict policy before conflicts occur
A conflict exists when two plausible changes compete for the same business state. "Last write wins" is easy to implement, but a timestamp does not know which system had authority or whether one change was still awaiting approval.
Use a policy that matches the field:
- authoritative source wins for fields with one owner;
- approved state wins over an unapproved proposal;
- higher-priority source wins for agreed fallback hierarchies;
- merge when changes affect independent fields;
- route to human review when the business meaning is ambiguous.
Microsoft's Azure SQL Data Sync documentation provides a concrete product example: a sync group defines direction, interval, schema, and either hub-wins or member-wins conflict behavior. The important lesson is broader than that service. Conflict handling is a declared part of the synchronization design, not an edge case to improvise later.
7. Design retries, verification, and evidence together
A timeout does not tell you whether the destination rejected a write or completed it before the response was lost. Blindly retrying can duplicate records or repeat a business action.
Use idempotent writes where possible, with a stable operation or event key that lets the destination recognize a repeated attempt. AWS Prescriptive Guidance recommends idempotent operations when retrying with backoff because partial updates can otherwise corrupt system state.
A completed API request is not enough. Verify the destination state when the business risk warrants it. Retain:
- source record and version;
- transformation or rule version;
- destination and operation key;
- attempt count and response;
- verified final state;
- exception owner and next action.
That evidence makes a failed flow recoverable instead of mysterious.
The governed synchronization loop
A useful synchronization design follows a loop rather than a straight arrow:
- Detect the change and retain a stable event or version reference.
- Identify the business record across source and destination systems.
- Check field authority, policy, approval state, and current destination version.
- Transform and validate the proposed destination value.
- Write with an idempotent operation key when the destination supports it.
- Read back or otherwise verify the intended destination state.
- Record success, retry a transient failure with limits, or route an exception to an owner.
The last two steps are where many diagrams stop being honest. Data was sent, but nobody checked whether the system now shows the intended value.
For distributed systems, immediate global consistency may be neither available nor necessary. Microsoft's guide to distributed data management explains why separately owned services often propagate updates through asynchronous events and accept eventual consistency. The operating requirement is then explicit: the team must know the permitted delay and how to detect records that never converge.
A Commerce example: product and inventory data
Consider a retailer using supplier feeds, a PIM, an ERP, an ecommerce platform, and two marketplaces.
The retailer might assign ownership like this:
- Supplier feeds propose source attributes and cost changes.
- The PIM owns approved product titles, descriptions, taxonomy, and media.
- The ERP owns cost, stock position, and financial identifiers.
- A pricing process owns the approved selling price for each market.
- Commerce and marketplace systems receive channel-specific records and report listing status.
A governed flow does not simply copy the whole product object in both directions. It stages supplier updates, resolves product identity, validates the proposed fields, sends content decisions to the PIM owner, combines approved content with current ERP and pricing state, and delivers only the fields each channel needs. It then reads back listing status and routes rejections.
This design avoids two common errors. The first is allowing a marketplace export to overwrite the PIM's approved product model. The second is treating the central layer as authoritative for stock or price when it is only carrying the latest approved decision from another system.
The Boost.space operational data layer is built around this kind of cross-system work: centralizing records, retaining remote IDs, deduplicating, synchronizing in both directions, and applying priority-based conflict rules. The architecture still needs a field-ownership contract. Technology can enforce a rule only after the team defines it.
Point-to-point, hub-and-spoke, or event-driven?
Point-to-point
Use direct connections when the path is bounded, ownership is simple, and the team can operate the mapping and recovery behavior. The risk rises as more systems reuse the same business record.
Hub-and-spoke
A hub can centralize identity, mappings, policy, and operational status. It reduces repeated pairwise logic, but it should not become a vague universal master. State which decisions the hub owns and which it only coordinates.
Event-driven
Events decouple a producer from several consumers and can support lower-latency propagation. They also introduce ordering, duplicate-delivery, schema-version, replay, and observability requirements. "Event-driven" is not the same as "automatically correct."
Many enterprises use a mix. A database may emit changes through CDC, a hub may resolve identity and policy, and destinations may be updated through APIs. Judge the whole operating path, not the label on one component.
Failure modes to test before launch
A production pilot should include failures on purpose:
- The destination times out after accepting the write.
- Two systems update the same field before the first sync completes.
- A record arrives without a stable identifier.
- A destination adds a required field or changes an enum.
- Events arrive out of order.
- A batch contains one invalid record among valid records.
- The sync is paused while source data continues to change.
- A user edits the destination while a retry is waiting.
- A delete, merge, or archived record propagates unexpectedly.
- The destination accepts the request but stores a different normalized value.
For each case, require a deterministic result: retry, skip, merge, compensate, quarantine, or send to review. Someone must own the queue.
How to start without redesigning the whole stack
Choose one business path with visible operational cost. Good candidates include supplier product updates, inventory availability, customer consent, order status, or approved audience activation.
Document one real record from source to destination:
- List every system and stable identifier involved.
- Assign authority for each field that moves.
- Set direction, trigger, and acceptable delay.
- Define transformations and validations.
- Write conflict and retry rules.
- Decide how completion will be verified.
- Name the exception owner and measure the waiting queue.
Measure the pilot with operational evidence: records processed, records verified, duplicates prevented, exceptions by cause, recovery time, and manual decisions retained. A connector count tells you nothing about whether the data is trustworthy.
The Commerce Revenue Blueprint is the next step when you need to map one of these flows against a live Commerce stack and put an owner and business outcome behind it. Enterprise teams comparing rollout and operating options can also review the enterprise approach and pricing.
Frequently asked questions
What is the difference between data integration and data synchronization?
Data integration combines or moves data so systems and people can use it together. Synchronization is a narrower operating concern: it keeps selected state aligned over time as source records change. An integration may be a one-time import. A synchronization flow has ongoing change detection, ownership, conflict, and recovery rules.
Does two-way sync mean both systems are sources of truth?
No. Two-way transport means updates can travel in both directions. Field authority can still differ. A CRM might own account status while a billing system owns payment status, with both values visible in each system.
Is real-time synchronization always better?
No. The right target is the freshness the business process needs. Lower latency increases operational demands around ordering, duplicate events, conflicts, and recovery. Scheduled synchronization can be safer and cheaper for fields that change slowly or require approval.
How should an enterprise handle sync conflicts?
Define conflict policy by field and business decision. Prefer one authoritative source where possible. Use approval state, source priority, or field-level merges when rules are clear, and send ambiguous cases to a named human owner. Do not rely on last-write-wins unless the business accepts what a timestamp can overwrite.
How do you know a synchronization flow succeeded?
Verify the intended destination state, not only the request response. Keep the source version, rule version, operation key, destination result, and final verification. Track exceptions until they are resolved or deliberately closed.
Last reviewed: August 10, 2026.
