Back to Notebook
Architecture Notes

Commerce Systems of Record

Ownership expectations across Shopify, PIM, ERP, and OMS, when part of an Enterprise Commerce Stack.

Summary

Most enterprise commerce instability does not come from scale, but from unclear ownership. Teams assume multiple systems can or should act as sources of truth, which leads to data integrity collisions, broken workflows, and brittle integrations. This note outlines some practical system-of-record models for Shopify-centric stacks and where responsibilities may often break down.

  • » Clear ownership boundaries help prevent cascading failures.
  • » Product vs Variant modeling deserves consideration.
  • » Conflict rules should be explicit and enforced by architecture design.
  • » Schema and data model changes should account for downstream systems impact.
System-of-Record Ownership Map

Use explicit ownership labels (Create, Enrich, Transact, Fulfill) to prevent collisions and inconsistent data. The below mapping assumes each of our favorite 3-Letter acronyms below is a Shopify-adjacent system-of-record included in the overall systems architecture. If it is not, for instance there is no PIM, then all product data would be created and enriched in Shopify.

Create Enrich Transact Fulfill

PIM

Enrich

Attributes, taxonomy, media metadata.

Shopify

Transact

Channel merchandising + checkout.

ERP

Create Transact

SKU creation, pricing, inventory.

OMS

Transact

Order routing and orchestration.

WMS

Fulfill

Pick, pack, ship, returns.

Product Data Flow

A typical ecommerce product lifecycle from creation through fulfillment (sync points shown implicitly by arrows).

ERP PIM Shopify OMS WMS
Conflict Resolution Flow

Default behavior when the same field changes in multiple systems.

Change detected in multiple systems
Check ownership table
Apply priority rule
Queue reconciliation + notify
Audit log + report collision

System Roles and Boundaries

Shopify, PIM, ERP, and OMS each solve different problems. Failure usually starts when two systems claim the same responsibility or when a responsibility is left undefined. Ownership should be explicit at the field level, not just at the system level.

Product vs Variant Modeling

Variant explosion is a common source of drift. PIMs often model attributes in a more abstract way than Shopify product options expect, which introduces change into workflows that may have been around for decades. Decide where variant logic lives and avoid duplicating it across systems. A key operational concept of Shopify that is always important to remember, Shopify expects consistentency in how data is modeled across core data concepts (product, variant, option, etc.).

Editorial vs Transactional Boundaries

Editorial data (descriptions, media, taxonomy) changes frequently and benefits from content workflows. Transactional data (price, inventory, fulfillment state) needs strict ownership and auditability. Attempting to merge these domains is a recipe for failure.

Sync Direction and Conflict Handling

  • Define a primary source of truth for each field.
  • Use one-way syncs where conflict is unacceptable.
  • When bi-directional is required, enforce field-level priority rules.
  • Record deltas and report drift instead of silently overwriting data.

Schema Evolution and Systems Impact

Schema changes ripple across catalog, search, merchandising, and analytics. Make schema changes intentional, versioned, and reversible. The cost of rework grows with every downstream consumer you add.

Key Takeaway

Clear data ownership and governance matter more than tooling. Well-defined boundaries prevent cascading failures as systems evolve.