Real-time multi-channel synchronisation: the architecture of a single catalogue

The same product is sold on your shop, on two marketplaces and on a B2B site. The logistics weight varies from one channel to another, the main image is not the same, and one marketplace has just rejected three hundred product listings due to a missing mandatory attribute. The problem isn’t the synchronisation itself: it’s that none of the systems knows which one holds the correct value. This article describes the architecture that eliminates these discrepancies — a single repository, outbound feeds by channel, latency tailored to the data type, and explicit conflict resolution.

The symptom: three channels, three versions of the same product

The discrepancy always starts small. A description is corrected directly in the shop’s admin panel because it’s quicker. A promotional price is entered in a marketplace’s back office to meet a sales deadline. A photo is replaced on the B2B site by the sales representative who has it to hand. Six months later, no one can say which version is the authoritative one, and the only way to find out is to open three tabs side by side.

The cost of this drift is rarely measured, but it is real and cumulative:

• Feed rejections— marketplaces and price comparison sites validate listings upon submission. One missing mandatory attribute, a non-compliant unit of measurement, an invalid EAN — and the product listing is simply not published. It does not appear anywhere, without anyone being alerted.
• Disputes and returns— a customer who receives a product that does not match the product listing on the channel where they made their purchase is entitled to return it. On marketplaces, these disputes have a direct impact on seller performance metrics.
• Over-selling and stock-outs— stock levels updated with a delay of several hours result in orders that cannot be fulfilled, or conversely, in items that are actually in stock being shown as out of stock.
• Correction time— the team spends time reconciling files rather than enriching the catalogue. This is the highest and least visible cost.

The cause: each channel has become its own source of truth

Technically, the cause is simple: the data has been duplicated at source rather than being transformed at the output. Each channel holds its own complete copy of the product, and each copy is editable. A system where three copies are editable without any arbitration never converges: it diverges, automatically, with every local modification.

The fix begins with an organisational decision, not a tool: defining the ownership of the data, field by field. For each attribute, only one system writes, the others read. This matrix usually fits on a single page and can be discussed in a single meeting.

Until this matrix is defined, no synchronisation will work: the connector will merely accelerate the spread of discrepancies. Applied to a single shop, it falls into three regimes — fields owned by the PIM, fields owned by the shop, fields written only at creation — as our article on synchronising a Shopify catalogue explains in detail.

The architecture: a central repository, outbound feeds per channel

The principle is as follows: the PIM holds the reference product data, and each channel receives a projection of this data, calculated at the time of publication. The catalogue exists only once; what varies is the way in which it is presented to each destination.

In practical terms, an outgoing feed is described in four layers:

• Selection— which products are sent to this channel. A marketplace does not necessarily receive the entire catalogue, and a B2B site often displays product listings that are not present on the consumer-facing site.
• Attribute mapping— the correspondence between the PIM data model and that of the channel: target field name, expected type, list of permitted values, unit. This is where compliance—and therefore the rejection rate—comes into play.
• Transformations— truncating a title to the maximum permitted length, unit conversion, image formatting, price rounding, concatenating several attributes into a single string. These rules reside within the data feed, never in the product record.
• Pre-send validation— a product whose mandatory attributes for the channel are not filled in is excluded from the feed and flagged, rather than sent only to be rejected at the other end. Rejection is handled before the call, not after.

This approach has an important practical implication: adding a channel no longer involves recreating a catalogue, but rather defining a new feed. At Pixee PIM, this is achieved via the native connectors — 15 e-commerce and marketplace connectors, 6 bidirectional ERP synchronisation modules. Whether your shop runs on Shopify, PrestaShop or WooCommerce, the logic remains the same: the PIM pushes, the channel receives. On the marketplaces, a single Mirakl connector provides access to around 400 marketplaces powered by this technology, each with its own attribute mapping — this topic is covered in more detail in our article on multi-marketplace distribution via Mirakl.

‘Real time’: what this actually means

The term is misleading. No distributed architecture is instantaneous: there is always some latency, and the real question is what level of latency is acceptable for which data. Two mechanisms coexist.

Event-driven synchronisation triggers a publish as soon as a value changes in the repository: a webhook or a message in the queue carries the identifier of the modified product, and the feed resumes immediately. The Scheduled synchronisation scans, at fixed intervals, the products modified since the last run and publishes them in batches — more economical in terms of API calls, and more predictable in terms of load.

The usual breakdown by data type:

• Stock— the most sensitive. Event-driven, with a trigger threshold to avoid sending an update for every unit sold.
• Prices— also event-driven, but with the opposite constraint: an update that is too frequent may trigger marketplace-side checks. A short time-based grouping before sending is preferable to a burst.
• Descriptions, attributes, translations— scheduled. Propagation over a few hours causes no issues, and batch processing allows for a completeness check before sending.
• Media— scheduled, outside peak hours. These are the heaviest loads and the slowest to process on the channel side.

Queuing and error recovery

An outbound stream without a queue is a stream that loses updates. Every publication must result in a persistent task: if the channel returns an error 429 (rate limit reached), 500 or a timeout, the task is requeued with an increasing timeout rather than abandoned. After several failures, it is moved to a queryable error queue, where an operator can see which product, which channel and which error message. It is not the normal operation that is costly, but the retries. Throughput matters as much as recovery: on shared hosting, a bulk push is enough to overwhelm a shop, hence the batching and rate control described in our article on PrestaShop synchronisation.

Conflicts: bidirectional, concurrent writing, idempotence

Some data flows are necessarily bidirectional. Stock levels are fed up from the ERP, orders are fed up from the channels, and during a migration the existing catalogue is fed up from the shop to the PIM. As soon as there are two directions of write operations, a rule for resolving conflicts is required.

• Priority by field, not by system— the correct level of granularity is not ‘the ERP takes precedence’ but ‘the ERP takes precedence on price and stock, the PIM takes precedence on description and media’. A value written by a system that does not own the field is ignored and logged, not applied. On WooCommerce this is very concrete: SEO and review plugins write to the same product as the catalogue, and a connector that rewrites it in full wipes their values — see our article on WooCommerce synchronisation.
• Timestamps and versions— each value carries its date of last modification and its source. In the event of concurrent writes to a field with shared ownership, the ‘latest write wins’ rule is only acceptable if the clocks are reliable and the audit trail is retained.
• Idempotence— re-running the same publication twice must produce exactly the same state on the channel side. This requires operations of the type upsert based on a stable business key (SKU or EAN, never a channel-internal identifier) and a request identifier to detect duplicates. Without idempotence, any recovery from an error carries the risk of duplicate records.
• Transaction log— knowing who modified what, when, and from which system. This is what enables a discrepancy to be resolved in a matter of minutes rather than half a day’s investigation.

The target transition point remains PIM-master mode: from a cutoff date onwards, product data is only updated in the repository. The back-office systems of the various channels are still used for orders, customers and editorial content, but no longer for product records. Conflicts can only be managed effectively once they have become rare. The road to that switch — initial export, mapping, sample validation, clean-up — is described step by step for Magento in our article on Magento and Adobe Commerce synchronisation.

What needs to be measured

Multi-channel synchronisation is managed using a few simple metrics, recorded by channel rather than in aggregate:

• Publication rejection rate— the proportion of products rejected by the channel, broken down by reason. A dominant reason almost always indicates a mapping rule that needs correcting, rather than products needing to be reviewed one by one.
• Propagation delay— the time elapsed between a change in the repository and its becoming visible on the channel. Monitor high values rather than the average: it is the tail of the distribution that causes incidents.
• Detected discrepancies— a periodic review compares the values present on each channel with the repository and lists any discrepancies. This is the only check that detects a manual change made in a back-office system.
• Completeness by channel— the proportion of the catalogue that can actually be published on each destination, taking into account its mandatory attributes. This indicator guides the enrichment work far more effectively than an overall completion rate.

Frequently asked questions

Should all channels be synchronised in real time?

No, and it would be counterproductive: more API calls, throughput limits reached more quickly, and increased load on the shop side. Reserve real-time updates for stock and price, and let descriptions, media and translations run through scheduled cycles. The right criterion is the cost of data being out of date for one hour: high for stock levels, negligible for a product specification.

How do you manage a channel that requires different titles or descriptions?

By using channel-specific values in the repository, not by making changes in the channel’s back office. The PIM stores the reference value and, where necessary, a variant for a given channel. The outbound feed selects the variant if one exists, otherwise the reference value. The data is edited in one place only and remains traceable.

What happens if a channel is unavailable for several hours?

Publications are queued and dispatched once service resumes, without any intervention: the queue’s role is to absorb the downtime rather than losing the updates. Set up a consolidation rule — if a product has been modified five times during the incident, only the latest version needs to be published.

Does the PIM replace the ERP in this architecture?

No. The ERP system retains ownership of the management data — stock levels, purchase prices, pricing, and accounts. The PIM owns the descriptive data and acts as the distribution hub to the channels. The two systems communicate: the bidirectional ERP synchronisation modules feed stock levels and prices back to the repository, which then propagates them across all channels.