Selling on multiple marketplaces: multichannel architecture on Azure

Selling on one marketplace is a project; selling on five becomes a system. Without a deliberate architecture, every new channel adds code, exceptions and fragility. The answer is a multichannel integration hub with a canonical model at its center.

The linear-growth problem

Connecting each internal system to each marketplace creates a number of connections that explodes with channels. The answer is to introduce a central point: the hub speaks one common language internally and many "dialects" towards marketplaces, through dedicated connectors.

The canonical model

At the center sits a neutral representation of business concepts: product, offer, order, shipment, financial movement. ERP and marketplaces hook into this model, not into each other. Changing or adding a channel does not touch the core.

Connectors and anti-corruption layer

Component	Responsibility
Marketplace connector	Speaks the specific API (eBay, Amazon, Shopify…)
Anti-corruption layer	Translates between canonical and channel models
Mapping	Attributes, categories, per-channel rules
Orchestration	Coordinates flows and states

The anti-corruption layer is the key: it prevents a marketplace's peculiarities from "contaminating" the internal model, keeping the core clean.

The main flows

• Catalog and offers: from the canonical model to marketplaces, in deltas;
• Stock and prices: fast propagation with buffers and per-channel price lists;
• Orders: from marketplaces to the canonical model and the ERP;
• Finances: payouts and fees reconciled per channel.

Architecture on Azure

On Microsoft Azure the hub is built with decoupled components: queues (Service Bus) for events, workers per connector, secure secret handling (Key Vault + Managed Identity), retry and rate-limiting patterns per API, and centralised observability with correlation IDs to follow an order across all steps.

Canonical model example

The canonical model should not copy eBay, Amazon or Shopify. It should represent your internal domain and leave translation to the connectors. A publishable product can be serialized like this:

{
  "sku": "ERP-12345",
  "title": { "it": "Scarpa running uomo", "en": "Men running shoe" },
  "brand": "Example",
  "identifiers": { "gtin": "8051234567890", "mpn": "RUN-12345" },
  "availability": { "warehouse": "IT-01", "quantity": 17, "safetyBuffer": 2 },
  "prices": [{ "currency": "EUR", "list": "retail", "value": 79.90 }],
  "attributes": { "color": "black", "size": "42" }
}

The eBay connector translates attributes into category aspects, Amazon into product type attributes, Shopify into options/variant metafields. The core should not know those details.

Operational case: adding the third channel

When you add Shopify after eBay and Amazon, you do not rewrite the ERP pipeline. You add a mapping table for locations, variants and images, a Shopify worker and a publication rule. Canonical events stay the same: ProductChanged, StockChanged, PriceChanged, OrderImported. This is where the hub pays back its initial cost.

Adding a new channel

With this model, integrating a new marketplace means writing a connector and defining the mapping, without touching the core or the other channels. That is how the architecture moves from "every channel is a new project" to "every channel is a configuration".

Common mistakes

• point-to-point integrations that grow explosively;
• a marketplace's peculiarities invading the internal model;
• mapping and rules duplicated for every channel;
• no observability across channels.

Conclusion

A multichannel hub with a canonical model, connectors and an anti-corruption layer turns complexity into scalability. It is the architecture that lets you sell on many marketplaces while keeping the system understandable, reliable and ready for the next channel.