Choosing Your Sync Model: Single Profile vs. Paired Profiles

This technical overview compares two implementation strategies for inventory synchronisation between stores: the standard Single Profile (Master-to-Destination) approach and the Paired Profile (Simulated 2-Way) approach.

Centralised

1. Synchronization Model Overview

Single Profile: Master → Destination

This model establishes a "Source of Truth" hierarchy. The Master store acts as the primary inventory controller, and the Destination store acts as a passive mirror.

• Direction: Updates only flow from Master to Destination.
• Conflict Resolution: The Master always wins. Any local changes made on the Destination store are eventually overwritten by the next sync from the Master.

Paired Profiles: Store A ↔ Store B

Users can create two separate profiles (A→B and B→A) to mimic a 2-way sync. However, the system treats these as independent processes rather than a unified, coordinated handshake.

• Direction: Bi-directional via two separate one-way tunnels.
• Conflict Resolution: Reactive. The system updates based on the most recent event received.

2. High-Volume Capability & Prevention

Handling peak events (8,000–9,000 movements per minute) requires understanding how each model handles high-concurrency "noise."

Looping and Over-Adjustment

• Single Profile: Inherently safe. Since data only moves in one direction, infinite loops are architecturally impossible. A built-in safeguard also prevents a store from being set as both Source and Destination in a single profile.
• Paired Profiles: Looping is generally mitigated by "Value Matching." If Store A updates Store B to a value of 10, and Store B tries to send that same 10 back to Store A, the system detects no net change and stops the bounce.

Peak Traffic Risks

• Single Profile: Extremely stable. Because there is no back-and-forth, there is no risk of "feedback loops" during high-volume sales.
• Paired Profiles: High Risk. There is no specialized safeguard for paired profiles during peak traffic. If simultaneous sales occur on both stores, "race conditions" can occur where webhooks arrive out of order, leading to inventory drift or overselling.

3. Edge Case Handling (Refunds, Restocks, & Transfers)

How the system responds to manual or order-based inventory changes depends entirely on whether a return path (the second profile) exists.

Master/One-Way Sync (Single Profile)

In this model, the Destination store is a "read-only" mirror regarding sync logic:

• Order CRUD (Refunds/Cancellations): Does not sync back. Stock recovered on the Destination stays local.
• Fulfillment Location Changes: Does not sync back.
• Manual Adjustments/Transfers: Does not sync back. The Master store remains unaware of these changes until it pushes a new update, which will overwrite the Destination’s manual changes.

Simulated 2-Way Sync (Paired Profiles)

Because there is a return profile (Destination → Master), local events on the "Destination" will impact the "Master":

• Order CRUD (Refunds/Cancellations): Yes. These trigger an inventory update that flows back to the Master.
• Fulfillment Location Changes: Yes, provided the change affects the specific location being watched by the sync profile.
• Manual Adjustments/Transfers: Yes. Any manual change on one store will trigger an update to the other.

Location Specificity: In a paired setup, the system only monitors the specific location configured in the profile. Furthermore, under high-volume stress, these edge-case updates are susceptible to the same drift risks mentioned in the High-Volume section.

Updated on: 06/05/2026