Adobe Commerce development
Storefront design
Performance & SEO
AI & agentic commerce
Release tracker
Ecommerce architecture is the set of layers that turn a shopper's request into a page, a cart and an order, and the systems that feed and consume that data. On Adobe Commerce, a sound reference architecture has seven layers: edge and CDN, storefront, APIs, the commerce core with its database, search, cache and queues, integrations (ERP, PIM, payments, tax), and data and analytics. The value of drawing it is less about the boxes and more about agreeing who owns each layer, what it depends on, and what happens when it fails.
The reference diagram
This is a simplified view of a typical Adobe Commerce setup. Not every store needs every box, but every store has to decide who owns each one.
Shopper / AI agent / mobile app
|
[ Edge: CDN, WAF, bot management, image optimization ]
|
[ Storefront: Luma or Hyvä theme | headless front end | Edge Delivery storefront ]
|
[ API layer: GraphQL, REST, API Mesh ]
|
[ Commerce core: PHP application, admin, cron, consumers ]
| | | |
[ MySQL ] [ OpenSearch ] [ Varnish + Valkey ] [ RabbitMQ ]
|
[ Integrations: ERP, PIM, OMS/WMS, payments, tax, CRM, App Builder ]
|
[ Data: analytics, warehouse, CDP, monitoring and logs ]Layer by layer, with ownership notes
| Layer | Typical components on Adobe Commerce | Usually owned by | Key decision |
|---|---|---|---|
| Edge | CDN, web application firewall, bot rules, image optimization | Hosting provider or Adobe on cloud; your team configures rules | What gets cached at the edge, and how bots and AI crawlers are treated |
| Storefront | Luma or Hyvä theme, a headless front end (for example Next.js), or Adobe Commerce Storefront on Edge Delivery Services | Front-end team or agency | Coupled theme vs headless; this choice drives most other costs |
| API layer | GraphQL and REST APIs, API Mesh to combine sources | Backend team | Which data the storefront reads from Commerce vs other systems |
| Commerce core | PHP application, admin, cron jobs, message queue consumers, custom modules | Backend team; Adobe patches the platform, you apply them (except on Adobe Commerce as a Cloud Service) | Which logic lives in modules vs out-of-process services |
| Database | MySQL or MariaDB, often with a read replica | Hosting or ops | Backups, replicas for reporting, upgrade path |
| Search | OpenSearch, or Live Search as a SaaS service | Ops for OpenSearch; Adobe for Live Search | Self-managed relevance vs SaaS merchandising |
| Cache | Varnish full page cache; Valkey (or Redis) for application cache and sessions | Ops and backend together | Cache hit rate targets and what invalidates pages |
| Queue | RabbitMQ (or ActiveMQ Artemis) for asynchronous work | Ops and backend | Which operations run async: exports, bulk updates, integrations |
| Integrations | ERP, PIM, OMS or WMS, payment gateway, tax engine, CRM, App Builder apps | Integration team; each external system has its own owner | Which system is master for products, prices, stock, customers and orders |
| Data | Web analytics, data warehouse, CDP, APM and logging | Data or marketing team; ops for monitoring | Single definition of revenue and orders across tools |
The commerce core and its services
For on-premises and cloud infrastructure deployments, Adobe publishes exact supported versions for each release. For Adobe Commerce 2.4.9, the on-premises requirements include PHP 8.5, MySQL 8.4 or MariaDB 12.3, OpenSearch 3, Valkey 9, RabbitMQ 4.3 (or ActiveMQ Artemis 2), Varnish 8, nginx 1.30 and Composer 2.10. Treat those as a set: upgrading Commerce usually means upgrading the services around it too, which is why upgrades should be planned as infrastructure projects.
Two parts of the core are easy to forget on a diagram and cause most production surprises: cron (indexers, emails, scheduled imports) and queue consumers (asynchronous operations). If either stops, the store looks fine while prices, stock and emails quietly go stale. Give them explicit monitoring.
Caching: the layer that decides performance
Most page requests on a healthy store never reach PHP. The CDN and Varnish serve cached pages, and personal data such as the mini-cart loads separately in the browser. When that design breaks, for example because a custom block makes pages uncacheable, every request hits the application and the database, and the store slows under load. Our explainer on Magento caching walks through each cache and how invalidation works.
Three architecture patterns
| Pattern | What changes | Fits | Trade-off |
|---|---|---|---|
| Coupled (monolith with theme) | Commerce renders pages with Luma or Hyvä | Most stores; smaller teams | Simplest to run; front end tied to the Commerce release cycle |
| Headless | A separate front end calls GraphQL; Commerce becomes a backend | Content-heavy brands, multiple front ends, teams with strong JavaScript skills | More flexibility; two applications to host, secure and keep in sync |
| Composable | Commerce is one service among several (search, CMS, OMS, pricing), joined through APIs and API Mesh | Large organizations with existing best-of-breed systems | Maximum choice; integration and ownership become the main cost |
Our guide to composable commerce explains when that last pattern pays off, and our guide to API Mesh for Adobe Commerce covers how Adobe's API Mesh combines several APIs into one GraphQL endpoint for a headless front end.
Integration principles that keep the diagram honest
- One master per data type. Write down which system owns products, prices, stock, customers and orders. Most integration bugs are two systems both believing they are the master.
- Async by default. Use the message queue or an integration layer for anything that can wait, so a slow ERP does not slow checkout.
- Out-of-process where it helps. Adobe's App Builder lets you run integration logic outside the Commerce application, which keeps the core lighter and upgrades simpler.
- Idempotent and replayable. Every integration should handle duplicate and late messages and be able to resend from a point in time.
- Observable. Each integration needs a dashboard or alert showing lag and errors, owned by a named person.
Ownership depends on the deployment model
The same diagram has different owners depending on how Adobe Commerce is deployed. On-premises, your team or hosting provider owns every box. On Adobe's cloud infrastructure, Adobe runs the underlying services and you own the application code, configuration and deployments. With Adobe Commerce as a Cloud Service, Adobe also hosts the application and applies feature and security updates automatically after a sandbox review period, and customization moves to extensions built outside the core, APIs and App Builder. Confirm the split for your edition and contract, because it decides who gets the call at 3 a.m.
Using the diagram
- Draw your current state with real product names and versions.
- Mark the owner, the monitoring and the failure impact of each box.
- Mark the master system for each data type.
- Highlight the boxes with no owner or no monitoring; that is your risk list.
- Draw the target state only after the current state is agreed.
Mistri uses this kind of diagram as the starting point for headless Adobe Commerce projects and for wider Adobe Commerce development work, because it makes trade-offs visible before anyone writes code.
Sources
System requirements (Adobe Experience League); Page caching (Adobe Commerce developer documentation); Message queues (Adobe Commerce developer documentation); Adobe Commerce GraphQL API (Adobe developer documentation); Adobe Commerce as a Cloud Service overview (Adobe Experience League).
