How Enterprise Omnichannel Teams Architect eCommerce Integrations Across ERP, OMS, and Marketplaces

Integration architecture is the part of enterprise eCommerce that determines whether the rest of the stack actually works. The storefront, the checkout, the loyalty program, and the marketplace presence all depend on data flowing correctly between systems that were never designed to talk to each other. When the integration layer is right, the stack feels coherent to customers and operators. When it is wrong, every other system inherits the dysfunction.

This guide walks through the architectural decisions enterprise omnichannel teams need to make before they pick a platform, build a connector, or sign a marketplace contract. The decisions covered here are not platform-specific in the abstract sense, but they have very concrete differences when you implement them on Adobe Commerce versus Shopify Plus.

Start With System-of-Record Decisions

Every successful integration architecture starts with one question, asked for every data type: where does the truth live. Product data, inventory, pricing, customer records, and order data each need a single system designated as the source of truth. Every other system in the stack consumes from that source, never overwrites it.

Product data typically belongs in a PIM (Salsify, Akeneo, inRiver) or, for smaller catalogs, in the ERP. The eCommerce platform consumes product data and renders it; it should not be the place where product attributes are authored.

Inventory belongs in the OMS or, for retailers without a dedicated OMS, in the ERP. The eCommerce platform should never be the source of truth for inventory because the moment you have a second sales channel (a marketplace, a POS, a B2B portal), the storefront’s view of inventory becomes obsolete.

Pricing is the hardest decision. Some retailers run pricing in the ERP, some in a dedicated pricing engine, and some in the eCommerce platform itself. The right answer depends on how complex the pricing logic is. If contract pricing, customer-tier pricing, and promotional rules cross enterprise boundaries, the pricing engine usually needs to be its own system. If pricing is mostly catalog-list with seasonal promotions, the eCommerce platform can hold it.

Customer data is increasingly held in a CDP (Segment, mParticle, Salesforce CDP) for marketing-driven organizations, with the eCommerce platform consuming a unified customer profile. For organizations without a CDP, the eCommerce platform usually holds customer data, with the ERP consuming order-derived customer records.

Orders are written to the eCommerce platform first, then handed to the OMS or ERP for fulfillment. The OMS becomes the system of record once the order is accepted; the eCommerce platform retains the customer-facing order history view but consumes status updates from the OMS.

Event-Driven Versus Batch Sync Patterns

The next architectural decision is how data moves between systems. There are two dominant patterns, and most enterprise stacks end up using both deliberately.

Event-driven sync uses a message bus (Kafka, AWS EventBridge, RabbitMQ) to publish changes as they happen. Order placed, inventory adjusted, price changed, customer updated. Subscribers consume the events and update their local state. This pattern is the right default for any data type where freshness matters: inventory, order status, pricing changes during a flash sale.

Batch sync runs on a schedule (every fifteen minutes, every hour, nightly) and reconciles state across systems. This pattern is the right default for data types where freshness matters less but completeness matters more: full product catalog refreshes, customer hierarchy updates from the ERP, pricing list updates that take effect at midnight.

The mistake enterprise teams make most often is choosing one pattern for everything. Pure event-driven architectures struggle with reconciliation: when an event is dropped or processed out of order, the consumer has no fallback. Pure batch architectures cannot meet the freshness requirements of marketplace inventory or flash-sale pricing. The right architecture uses event-driven for the high-velocity data and scheduled batch reconciliation as the safety net.

For Adobe Commerce specifically, the Adobe Commerce architecture documentation covers the message queue patterns the platform supports natively. Bemeir’s enterprise Magento engagements typically combine native message queue handlers for low-latency events with batch jobs running through Magento’s cron framework for the reconciliation layer.

Idempotency and Conflict Resolution

The integration architecture only works if the same event can arrive twice without causing damage. Idempotency is not optional in production eCommerce; it is the precondition for surviving network errors, broker retries, and partial failures.

Every consumer in the architecture needs an idempotency strategy. The two common patterns are deduplication-by-event-id (the consumer maintains a record of processed event IDs and skips duplicates) and idempotent-by-design state changes (the operation is structured so that applying it twice has the same effect as applying it once). The first pattern is more common; the second is more elegant when it fits.

Conflict resolution is the harder problem. When two systems disagree about the state of a record (the eCommerce platform thinks the customer’s shipping address is one thing, the ERP thinks it is another), the architecture needs a deterministic rule for who wins. The system-of-record decision from the first section answers most of these questions, but edge cases (the customer updated the address in the storefront after a sync ran) require explicit handling.

Marketplace Feed Generation

Marketplaces (Amazon, Walmart, eBay) are the integration layer most likely to expose architectural weaknesses because each marketplace has its own product data model, its own order management API, and its own quirks for inventory and pricing.

Amazon expects a flat product file with marketplace-specific attribute names and category-specific required fields. Walmart’s API is similar in shape but different in detail. eBay’s category structure changes frequently. A marketplace integration architecture that hardcodes any one marketplace’s data model will need to be rewritten for every additional channel.

The pattern that holds up is a marketplace abstraction layer: a normalized internal representation of products, inventory, and orders, with a per-marketplace adapter that translates the internal representation into the marketplace’s expected format. Adding a new marketplace becomes adapter work rather than core data model changes.

POS Sync and OMS as the Integration Broker

For omnichannel retailers, the POS adds another integration vector. The POS is generating sales, capturing inventory adjustments, and creating customer records, all in real time at every store location. Connecting the POS directly to the eCommerce platform is a tempting shortcut and a long-term mistake. The POS-to-eCommerce direct connection becomes brittle as soon as a third channel (a marketplace, a B2B portal) needs the same data.

The pattern that scales is the OMS as integration broker. The OMS becomes the central nervous system: every channel (web, POS, marketplace, B2B) reads inventory from the OMS and writes orders to the OMS. The OMS handles fulfillment routing, inventory allocation, and order lifecycle. The eCommerce platform talks only to the OMS for inventory and order data; it does not need to know about the POS or the marketplaces directly.

Where Adobe Commerce and Shopify Plus Differ on Integration Extensibility

Both platforms support enterprise integration patterns, but they take different approaches.

Adobe Commerce offers deeper extensibility through its module architecture, native message queue support, and full database access for custom integrations. The trade-off is that this extensibility requires real engineering: custom modules, observer patterns, message queue consumers, and proper ORM usage. A team without senior Magento engineers will produce integrations that work but generate technical debt.

Shopify Plus offers cleaner integration primitives through Shopify Functions, Flow, and the GraphQL Admin API. The trade-off is that the platform’s flexibility is bounded: integration patterns that fall outside the supported APIs are either impossible or require workarounds through external middleware. Bemeir’s Shopify Plus engagements lean heavily on the Shopify Dev documentation and treat external middleware as a deliberate architectural choice rather than an afterthought.

Data Type to Sync Pattern Reference Table

How to Use This Architecture

The pattern that works for enterprise omnichannel teams is to make the integration architecture decisions before the platform selection is finalized. Once the systems-of-record, sync patterns, and broker topology are documented, the platform selection is a question of which platform supports the architecture cleanly. References from Forrester, Gartner, and Digital Commerce 360 consistently show that integration debt is the single largest source of post-launch friction in enterprise eCommerce.

Integration capability is not a feature of any individual platform. It is a property of the architecture, the team that designs it, and the discipline of maintaining the system-of-record contracts over time. Bemeir runs the system-of-record exercise as a fixed first deliverable on every enterprise omnichannel engagement for exactly this reason. The teams tha