Adobe Commerce Has Evolved — And It's Changing What Backend Development Means
Magento as you knew it is gone. What Adobe has built in its place is a composable, API-first, cloud-native commerce platform — and the implications for backend engineers are profound. Here's exactly what changed, why it happened, and what you need to know right now.
From Open-Source Monolith to Composable Commerce Platform
When Adobe acquired Magento in 2018, the platform was already one of the most powerful — and complex — ecommerce systems in the world. Since then, Adobe has methodically dismantled the monolithic architecture and rebuilt it as what it now officially calls a "composable ecommerce solution."
According to Adobe's official product page, Adobe Commerce is today "a composable ecommerce solution that lets you quickly create global, multi-brand B2C and B2B experiences — all from one cloud-native platform." That single sentence represents years of architectural transformation that every backend developer working with this platform needs to understand.
The shift didn't happen overnight. It was a deliberate, staged evolution — from the introduction of PWA Studio and GraphQL in version 2.3, through the rollout of SaaS-based Merchandising Services, to the launch of Adobe Commerce as a Cloud Service and the new Edge Delivery Services-powered storefront. Each release moved the platform further away from its monolithic roots.
The Old Magento
- 🔗 Tightly coupled frontend & backend
- 📄 Layout XML & PHTML templates
- 🧱 Business logic buried in core PHP
- 🔄 Upgrade cycles & manual patching
- 🖥️ Single monolithic deployment
Adobe Commerce Today
- 🔌 API-first, headless by design
- ⚛️ Edge Delivery Services storefront
- ☁️ SaaS Merchandising Services
- 🔁 Continuous delivery, no manual upgrades
- 🌐 Distributed, composable architecture
What Adobe Actually Built: The Four Pillars of Modern Commerce
Based on Adobe's own developer documentation and the Adobe Commerce as a Cloud Service overview, the modern platform rests on four distinct layers — and each one demands different skills from a backend engineer.
1. The Headless Commerce Storefront
The frontend is now fully decoupled. Adobe's official documentation for Commerce as a Cloud Service explicitly states: "Commerce Storefront is fully headless with a decoupled architecture that provides all Merchandising Services and data through a GraphQL API layer."
Importantly, the new storefront is powered by Edge Delivery Services — not a React SPA in the traditional sense, but a performance-first, document-based authoring framework designed to achieve top Google Lighthouse scores. The same official docs note it supports "simple document-based authoring or visual editing with Storefront Builder." The old Luma theme? Adobe Commerce as a Cloud Service does not support Luma storefronts at all.
2. SaaS Merchandising Services
Search, product recommendations, and catalog management are no longer part of the core PHP application. They are Adobe-hosted SaaS services. According to the official product availability documentation, these include Live Search, Product Recommendations, Catalog Service, and Payment Services — each versioned independently and compatible with Commerce 2.4.4 and later.
The performance gains are significant: Adobe states the SaaS-based Catalog Service delivers 10x faster data retrieval on category, product detail, and search pages compared to querying the core database directly. These aren't optional add-ons anymore — they are the recommended architecture for any serious implementation.
3. Out-of-Process Extensibility via App Builder
This is perhaps the most significant shift for backend developers. Adobe's developer documentation is explicit: "Adobe recommends using the out-of-process extensibility method where possible."
The toolset for building these out-of-process extensions includes Adobe App Builder (a serverless runtime for deploying isolated microservices), API Mesh (which allows you to combine GraphQL, REST, and other sources into a single queryable endpoint), Adobe I/O Events (for event-driven triggers), and the Integration Starter Kit to accelerate ERP/CRM integrations with pre-built templates and onboarding scripts.
4. Cloud-Native Infrastructure with Auto-Scaling
Adobe Commerce on Cloud Infrastructure — the foundation of all enterprise deployments — provides a "secure automated hosting platform" built for enterprise scale. The platform supports over 200,000 orders per hour during peak events, with a distributed architecture and auto-scaling capabilities.
With Adobe Commerce as a Cloud Service, continuous delivery means there are no manual upgrades. Adobe sends in-app notifications when updates are available, with a 30-day sandbox evaluation window before they are automatically applied to production. Adobe guarantees backward compatibility for all updates — provided your customizations follow the API-first extensibility model.
Three Extensibility Models: Which One Do You Use?
According to Adobe's official developer documentation, there are now three recognized patterns for extending Adobe Commerce. Understanding which to apply — and when — is a core competency for any backend engineer on this platform.
In-Process Extensibility (Traditional PHP)
Custom PHP code that runs within the same process as the core application. This is the model most developers know — plugins, observers, di.xml, preferences. It offers direct access to core functions and low latency, but extensions share resources with the application core and a poorly written extension can destabilize the entire site. Adobe restricts this model to specific use cases: creating blocks for native templates and modifying core objects like customers, orders, and products.
Out-of-Process Extensibility (App Builder)
Custom code and services that run in a completely separate process — on Adobe's serverless runtime (App Builder) or any external cloud service. Adobe's own documentation gives a concrete example: an Order Export Service built on App Builder that uses webhooks to receive order events from Commerce, transforms the data, and pushes it to an external OMS. The Commerce core is never touched. This model provides isolation, independent scaling, and technology freedom — you can use any language or framework alongside PHP.
Hybrid Extensibility
The combination of both models. Adobe's docs describe a scenario where an App Builder service needs additional data not available through the standard GraphQL or REST APIs — requiring a custom in-process extension to modify the GraphQL response on the Commerce side, while the orchestration logic lives entirely outside of the core. This is the most architecturally demanding pattern, requiring careful coordination between both layers.
What This Actually Means for Backend Engineers
Here is the honest summary: the role of an Adobe Commerce backend engineer has changed more in the last three years than in the previous decade. You are no longer primarily a PHP developer who extends a monolith. You are a distributed systems engineer who happens to work in a commerce context.
GraphQL Fluency
GraphQL is the contract between the frontend and all backend services. You need to be able to design schemas, extend existing queries, and use API Mesh to combine multiple data sources.
Serverless & App Builder
Building integrations on Adobe App Builder means understanding serverless architecture, event-driven patterns, and the Adobe I/O Runtime environment.
Integration Architecture
The Integration Starter Kit provides reference patterns for ERP, CRM, and PIM integrations. Understanding the standardised architecture it provides is a significant time-saver.
Event-Driven Thinking
Webhooks and Adobe I/O Events replace the old observer model for cross-system communication. Designing reliable, retryable event flows is now a core skill.
Distributed Systems
When services scale independently, you must design for eventual consistency, handle API rate limits, manage retries, and understand the distributed data flow across the full platform.
PHP Still Matters
In-process extensibility isn't going anywhere. Deep PHP knowledge — plugins, preference injection, service contracts — remains essential for modifying core Commerce behaviour correctly.
The Enterprise Reference Architecture: A Blueprint for Modern Implementations
Adobe publishes an official Enterprise Reference Architecture for Commerce, documented on Experience League. It describes the modern approach as requiring Commerce to integrate with Adobe Experience Cloud solutions — including Real-Time CDP for audience activation, Adobe Journey Optimizer for personalised campaigns, and AEM Assets for digital asset management.
The architecture documentation explicitly states that "adopting a modern implementation approach that uses Adobe's latest composable commerce solutions is critical to the success of enterprise businesses." This is no longer a suggestion — it is the official recommended path for any serious enterprise project.
Enterprise Architecture at a Glance
Commerce Foundation
Cloud-native PHP core on auto-scaling infrastructure. GraphQL & REST APIs. Multi-site, multi-brand, B2B & B2C from a single instance.
SaaS Merchandising Layer
Live Search, Product Recommendations, Catalog Service & Payment Services. All Adobe-hosted with independent versioning.
Developer Extension Platform
App Builder, API Mesh, I/O Events, Webhooks, Admin UI SDK, and Integration Starter Kit for back-office systems.
Experience Cloud Integration
Data Connection to Real-Time CDP. Integration with Adobe Journey Optimizer. AEM Assets for product visuals.
Who Is Adobe Commerce Actually Built For Now?
This is an important question to answer honestly. Adobe's own materials are clear that this platform is engineered for a specific type of business — and it is not the right fit for everyone.
The platform is purpose-built for enterprises that need to handle massive scale: Adobe cites the ability to process over 200,000 orders per hour, manage millions of SKUs with thousands of prices per SKU, and support multi-brand, multi-site, multi-currency operations from a single platform. It is designed for businesses with complex ERP and CRM integration requirements, where the Integration Starter Kit and App Builder provide real leverage.
✅ Strong Fit For
- 🏢 Enterprise B2B and B2C commerce
- 🌍 Multi-brand, multi-region operations
- 🔗 Complex ERP / CRM / PIM ecosystems
- 📈 High-volume, high-SKU-count catalogs
- 🤖 Brands investing in AI-driven personalisation
- 🛒 B2B self-service portals with negotiated pricing
⚠️ May Not Be the Right Fit For
- 🏪 Small merchants with limited budgets
- 📦 Simple, single-catalog stores
- 👤 Teams without engineering depth
- 🚀 Startups needing fast, cheap deployment
- 🔧 Projects with no integration complexity
For simpler use cases, platforms with lower architectural overhead may offer a better total cost of ownership. Adobe Commerce's power comes with proportional complexity — and proportional investment.
The Practical Impact: What Developers Experience on Real Projects
The documentation tells one story. What does it mean in practice? Here are the concrete changes any experienced Magento developer will notice when working with modern Adobe Commerce implementations.
No more upgrade marathons. On Commerce as a Cloud Service, Adobe pushes updates continuously with backward compatibility guarantees. The previous upgrade process — cloning instances, running compatibility tools, resolving code conflicts — is explicitly described as "no longer necessary." Your customisations simply need to follow the API-first extensibility model to remain compatible.
Extensions now live outside the codebase. With App Builder as the recommended extensibility layer, new integrations are deployed as isolated applications on Adobe's serverless infrastructure. They can be installed, scaled, and updated without touching the Commerce installation. This is a fundamental change to the development and deployment workflow.
GraphQL is not optional. The headless storefront communicates exclusively through GraphQL. The Commerce as a Cloud Service architecture provides "all Merchandising Services and data through a GraphQL API layer." If you have been deferring GraphQL expertise, that deferral is no longer viable.
Performance benchmarks have shifted. When the SaaS Catalog Service delivers 10x faster data retrieval than querying the core database, and the platform is engineered to achieve top Google Lighthouse scores out of the box, the performance bar for custom implementations rises accordingly. Developers who create in-process bottlenecks will be working against a platform that was optimised to avoid them.
Provisioning is minutes, not days. The Cloud Manager self-service portal can spin up sandbox and production instances in minutes, with Merchandising Services, the headless storefront, and App Builder pre-configured and integrated. This fundamentally changes project kickoff workflows and developer environment management.
Key Takeaways for Backend Engineers
Adobe Commerce is officially a composable commerce platform — this language comes directly from Adobe's product documentation, not from analysts. The monolith is not coming back.
Out-of-process extensibility via App Builder is the recommended default. PHP plugins remain valid for specific scenarios, but the architectural direction is clear.
GraphQL is the primary data contract. The headless storefront and all SaaS services communicate via GraphQL. Backend engineers must be fluent in schema design and API Mesh.
SaaS services are the performance layer. Live Search, Product Recommendations, and Catalog Service deliver measurably better performance than the core database. They are the recommended architecture, not optional extras.
Architectural thinking is now mandatory. Choosing between in-process, out-of-process, and hybrid extensibility — and understanding the trade-offs of each — is a core decision every backend engineer will face on modern implementations.
The Road Ahead: Agentic Commerce and AI-Native Shopping
Adobe is not stopping at composable. The company has publicly committed to what it calls agentic commerce standards — helping brands "capture demand across AI-native shopping channels, while maintaining full control over customer relationships and brand experiences." This signals the next wave of backend complexity: commerce logic that must respond not just to human browsers, but to AI agents, voice interfaces, and automated purchasing systems.
The 13 types of AI-powered product recommendations already in the platform — covering shopper history, frequently paired items, visual similarity, and trending products — are a preview of this direction. The backend engineers who will thrive are those who understand how to expose clean, well-documented APIs that these intelligent systems can consume reliably.
Adobe Commerce is not becoming easier. It is becoming more capable, more distributed, and more demanding of the engineers who work with it. The reward for that investment is a platform built to handle the scale, personalisation, and integration complexity that enterprise commerce actually requires.
The Bottom Line
Adobe Commerce has evolved from a PHP monolith into a composable, API-first, cloud-native platform. Backend development on this platform now means designing GraphQL APIs, orchestrating out-of-process services on App Builder, connecting SaaS Merchandising layers, and thinking in distributed systems — not just writing PHP extensions.
The shift is real, it is documented, and it is accelerating. The engineers who understand this transformation — and invest in the new skill set it demands — are the ones who will lead the next generation of enterprise commerce projects.