> ## Knowledge Base Index
> Fetch the complete knowledge base index at: https://help.stock-sync.com/sitemap.xml
> Use this file to discover available pages before exploring further.
> Pure-Markdown content can be obtained by appending a '.md' suffix to the content URLs listed in the sitemap (without the trailing slash).

# 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
| Feature | Single Profile (Master-to-Destination) | Paired Profiles (Simulated 2-Way) |
| ---- |
| **Logic Type** | Strict One-Way / Master-Source | Two concurrent One-Way streams |
| **Source of Truth** | Centralised (Master Store) | Distributed (Both stores update each other) |
| **Complexity** | Low; high data integrity | High potential for race conditions |


### 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.