# Keeping prices, stock and statuses consistent across several platforms

> Keeping prices, stock or order status consistent across several platforms that don’t speak the same technical language is a need that keeps coming back in very different shapes.

- Source canonique : [https://allaux.fr/en/expertises/synchronisation-multiplateforme-temps-reel](https://allaux.fr/en/expertises/synchronisation-multiplateforme-temps-reel)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## The typical need

As soon as a business sells or operates on more than one channel — several shops, a marketplace alongside its own site, a delivery app alongside a physical shop — the question of data consistency across those channels comes up quickly. A price changed in one place needs to show up elsewhere, an out-of-stock item needs to disappear everywhere, an order placed on one channel needs to be visible in the overall management system. Without synchronisation, each channel lives in its own reality, and the gaps that build up always end up costing money, whether through overselling, price inconsistency, or a missed order.

## How I approach this kind of need

I start by identifying a source of truth for each type of data to synchronise: which system is authoritative for stock, which system is authoritative for prices — these two answers aren’t necessarily the same system. From that source, I build the connectors to each target platform, with a sync frequency matched to how critical the data actually is: stock that affects sellable availability deserves tight real time, editorial content can make do with a daily sync.

True real time — an update propagated within seconds — isn’t always necessary or economically justified. I always discuss the actual need before building an architecture more complex than it needs to be: syncing every few minutes is more than enough for many uses, with an architecture that’s far simpler and more robust than a strict real-time system, which brings its own risk of disorder during a load spike or a partial outage.

## Factors that affect the quote

- **Number of platforms to synchronise** — Each extra platform adds a connector and a potential point of failure to monitor.
- **How critical real time actually is** — True real time calls for a more demanding event-driven architecture than synchronisation scheduled at regular intervals.
- **Conflict handling** — If several systems can modify the same data, a clear priority rule needs to be defined and implemented, which adds complexity.
- **History and audit trail** — Keeping a record of synchronisations to diagnose a discrepancy after the fact takes extra logging work.

## Questions worth asking before starting

> Is real time genuinely necessary, or does regular synchronisation cover the actual use? Which system should be authoritative when the same data disagrees across systems? How can you quickly spot that a platform is no longer syncing correctly?

## FAQ

### Is true real time always preferable?

No, it answers a specific need but adds extra complexity and maintenance cost; a well-sized regular sync is enough for many use cases.

### How are conflicts handled when two platforms modify the same data?

A clear priority rule, defined before development, settles it automatically; ambiguous cases spotted in advance get discussed with the client before going live.

### What happens if a platform is temporarily unavailable?

Updates meant for that platform are queued and replayed as soon as it becomes reachable again. As long as the queue holds and the platform accepts the replay, nothing is lost and no manual intervention is needed; a very long outage, or a replay the remote platform rejects, still has to be handled by hand.

### Does this approach hold up as more platforms get added over time?

Yes, an architecture built around a single source of truth makes adding a new platform easier, since it becomes one more connector rather than a rebuild of the existing system.