Adobe Commerce integration architecture

A web store rarely stands alone: around Adobe Commerce work an ERP, a PIM, an OMS, a payment provider, a search engine, a CDN and a message queue. Click any element to see its role, or start the path of an order and follow step by step where the data goes. The other pages of the series show one mechanism each with real, running PHP.

The path of an order

1/9

Click an element (or focus it with Tab and press Enter) for details. The orange dot follows the data flow of the current step.

The PIM sends product data and Commerce saves it. With scheduled indexing the change goes to the changelog, cron reindexes it in batches, and the search index (OpenSearch) is updated too.
Open demo: Indexer & message queue

Selected element

Adobe Commerce

PHP · MySQL · cron

Catalog, pricing, cart, checkout and order management. It serves the storefront from indexes and puts slow or external work on a message queue.

Typical integration

REST and GraphQL APIs, bulk and asynchronous REST endpoints, event handlers (observers, plugins), cron jobs and message queue publishers.

Open demo

Live demos in the series

Cart engine

Cart price rules with priority, coupons, condition trees and "discard subsequent rules".

Layered navigation

Facet filtering with correct counts that respect the other filters, on a 240-item catalog.

Indexer & message queue

Update on Save vs Update by Schedule with a changelog and cron batches; a message queue with retries and a dead-letter queue.

GraphQL query

A visual builder, a custom PHP GraphQL parser, depth and complexity limits, batched resolvers.

Why is a Commerce integration built like this?

The store is responsible for the shopping experience, not the owner of every piece of data: product data lives in the PIM, finance and often stock in the ERP, fulfilment in the OMS. A good integration therefore states clearly which system is the source of truth for which data, and data flows in one direction only.

A synchronous call (the shopper waits for the answer) is justified where a decision is needed at once: payment authorisation, a stock check in the cart. Everything else, such as order export or stock sync, is asynchronous: on a message queue, with retries, so an outage of an external system does not stop sales.

Performance comes from caching and indexes: the CDN serves most pages without touching Commerce, and Commerce answers from precomputed indexes. The price is always a small delay, which has to be managed deliberately (targeted cache purge, scheduled indexing).

The diagram is a general, deliberately simplified pattern, not a description of a specific system: real projects often have an intermediate integration layer (middleware, iPaaS), several warehouses and sales channels, and SaaS services (for example search or recommendations).