Magento is a PHP-based ecommerce platform that generates online storefronts by combining a modular codebase, a flexible database design, and a layered rendering system. When a shopper visits a Magento-powered store, the platform routes the request through a series of internal steps: matching the URL to the right controller, pulling product and customer data from a MySQL (MariaDB) database, assembling the page layout from XML instructions and template files, and sending back finished HTML. Understanding each of these layers explains why Magento can power everything from a small catalog to a multimillion-SKU enterprise operation.
The Technology Stack
Magento runs on a conventional web stack, but each layer is tuned for ecommerce workloads. At the base sits a web server, typically Nginx or Apache, which accepts incoming browser requests and handles SSL/TLS encryption. Behind the web server, PHP does the heavy lifting: executing business logic, calculating prices, applying catalog rules, and coordinating with other services.
The database layer uses MySQL or its drop-in replacement MariaDB to store products, customers, orders, and configuration. For speed, Magento relies on Redis as an in-memory cache for session data and full-page output, and it uses a message queue service (RabbitMQ or ActiveMQ) to handle background tasks like order processing and inventory updates without making the shopper wait. A search engine, typically Elasticsearch or OpenSearch, indexes the catalog so product searches return results in milliseconds instead of running expensive database queries on every keystroke.
When hosted on Adobe’s cloud infrastructure, the stack also includes a Fastly CDN layer that caches pages at edge servers around the world and provides built-in DDoS protection. Fastly’s image optimization service resizes and compresses product images on the fly, which frees the application servers to focus on processing orders rather than manipulating files.
How the Database Stores Products
Most web applications store each type of record as a row in a table with fixed columns. Magento takes a different approach for catalog and customer data, using what’s called an Entity-Attribute-Value (EAV) model. Instead of one wide table with a column for every possible product detail, the EAV model splits data into three parts: the entity (for example, a single product), the attribute (like “color” or “price”), and the value associated with that attribute (“red” or “$49.99”). Each of these lives in its own table.
This design solves a real ecommerce problem. A clothing store might need attributes for fabric, sleeve length, and fit, while an electronics store needs voltage, screen size, and connectivity type. In a traditional table structure, every product row would contain dozens of empty columns for attributes that don’t apply. The EAV model avoids storing those empty values entirely, which conserves space and keeps the database cleaner. More importantly, store administrators can add new attributes, like a “sustainability rating” or “battery life,” without altering the underlying database structure. No columns need to be added, no migrations need to run. This flexibility is a big reason Magento scales well for stores with diverse or rapidly changing catalogs.
The tradeoff is complexity. Pulling a single product’s full set of details requires joining several tables, which can slow down read-heavy pages. Magento compensates by offering flat index tables that periodically consolidate EAV data into a more traditional format for faster storefront queries, essentially giving you the flexibility of EAV for administration and the speed of flat tables for shopping.
How a Page Request Flows
Every time a shopper clicks a link or loads a category page, Magento follows a predictable sequence of steps to build the response.
First, the web server receives the HTTP request, terminates the SSL connection, and passes the request into the PHP application. The entry point is a single file (pub/index.php) where the Bootstrap class initializes the Magento application, loads configuration, and hands control to the framework.
Next comes routing. A component called the Front Controller examines the URL pattern and loops through a set of routers in a specific order. Each router checks whether it knows how to handle the URL. The first match wins. For a URL like /catalog/product/view/id/42, the standard router recognizes “catalog” as the module, “product” as the controller, and “view” as the action.
The matched router then calls the controller’s execute() method. This is where business logic runs: loading the product from the database, checking stock status, applying pricing rules, and preparing the data that templates will need.
Finally, the layout and rendering system takes over. Magento reads XML layout files that define the structure of the page: which blocks appear in the header, sidebar, main content area, and footer. Each block is a PHP class that prepares a specific chunk of data. Template files (written in PHP with HTML) take that data and render the actual markup. The assembled HTML response travels back through the web server to the shopper’s browser. On subsequent visits, cached versions of the page can skip most of these steps entirely.
Modules and Customization
Magento’s codebase is organized into modules, each responsible for a specific piece of functionality. There are modules for the catalog, checkout, customer accounts, shipping, tax, payments, and dozens of other features. Each module contains its own controllers, models, database schemas, layout XML, and templates. This separation means you can modify or replace one area of the store without touching unrelated code.
The primary customization mechanism is dependency injection, a design pattern where objects declare what they need (usually as interfaces) and the framework supplies the concrete implementations. The mapping between interfaces and their implementations lives in configuration files called di.xml. If you want to change how Magento calculates shipping rates, you write a new class that implements the same interface and update the di.xml to point to your version. The rest of the system continues calling the same interface without knowing anything changed underneath.
Beyond full class replacement, Magento offers two lighter-weight extension points. Plugins (also called interceptors) let you run code before, after, or around any public method on almost any class, without rewriting the original. Observers listen for specific events that Magento fires during its lifecycle, like “customer_login” or “sales_order_place_after,” and execute custom logic in response. These tools mean most customizations layer on top of the core rather than modifying it directly, which makes upgrades far less painful.
The Object Manager ties all of this together. During the bootstrap process, it reads the di.xml configuration, determines which classes to instantiate, and injects the right dependencies into each constructor. Injectable objects are typically singletons, created once and reused. Objects that need a fresh instance every time, like an individual order line item, are produced through factory classes that the Object Manager also manages.
Open Source vs. Adobe Commerce
Magento exists in two versions that share the same core architecture but differ significantly in features and support. Magento Open Source is free, available on GitHub, and provides the fundamental ecommerce functionality: catalog management, checkout, customer accounts, and the full module and extension system described above. You download it, host it on your own servers or a hosting provider, and manage updates yourself.
Adobe Commerce (the paid, enterprise tier) wraps that same core in a managed cloud infrastructure running on AWS or Azure. It adds features aimed at larger or more complex operations: AI-driven product recommendations and search, built-in B2B commerce tools (company accounts, negotiated quotes, requisition lists), advanced personalization, and deeper integration with other Adobe products for analytics and content management. The cloud version also handles infrastructure scaling, security patching, and performance optimization as part of the service.
For a small to midsize store with straightforward requirements, Open Source plus a reliable hosting provider covers the essentials. For businesses that need B2B workflows, AI-powered merchandising, or the operational simplicity of a managed platform, Adobe Commerce bundles those capabilities without requiring you to piece them together from third-party extensions.
How It All Connects
The power of Magento’s architecture comes from how these layers interact. The EAV database gives store owners the freedom to model any type of product without developer intervention. The module system lets agencies and in-house teams add features or integrate third-party services without forking the core. The request lifecycle provides clean separation between routing, business logic, and presentation, so a change to how prices are calculated doesn’t require touching template files. And the caching and CDN layers ensure that all of this complexity doesn’t translate into slow page loads for shoppers.
When you install an extension from the Magento Marketplace, it plugs into these same systems: registering its own routes, declaring dependencies through di.xml, hooking into events with observers, and adding layout XML to inject new blocks onto existing pages. The architecture is designed so that dozens of extensions from different developers can coexist without conflicting, as long as each follows the framework’s conventions.