Magento 2 is a modular, PHP-based e-commerce platform that handles everything from product catalog management to checkout and order fulfillment. Now maintained by Adobe under the name Adobe Commerce, it runs on a layered architecture where each piece of functionality lives in its own module, communicating through well-defined APIs. Understanding how these layers fit together helps you evaluate whether Magento 2 is right for your store, plan customizations, or simply make sense of what’s happening under the hood.
Modular Architecture
Magento 2 is built around modules. A module is a self-contained package of code responsible for one area of functionality: catalog browsing, shopping cart logic, customer accounts, payment processing, shipping rules, and so on. The core platform ships with hundreds of these modules, and you can add, remove, or replace any of them without rewriting the rest of the system.
This modular design is reflected in the file structure on the server. Three directories matter most:
- vendor/ holds the core framework and any modules installed through Composer, PHP’s package manager. You generally don’t edit files here directly because updates will overwrite your changes.
- app/code/ is where your custom modules and third-party extensions live, organized by company name and module name (for example, app/code/YourCompany/CustomShipping). This separation keeps your work isolated from core code.
- pub/ is the public-facing directory. It contains the entry point for the web server, static assets like CSS and JavaScript, and media uploads. Pointing your web server to pub/ instead of the root directory adds a layer of security by keeping application files out of public reach.
Each module can declare dependencies on other modules, register its own database tables, define API endpoints, and inject its own templates into the storefront. When Magento boots up, it reads each module’s registration file and wires everything together through a dependency injection system. That system lets you swap out a class (say, the default tax calculator) with your own version by editing a configuration file rather than modifying the original code.
How the Database Stores Product Data
Magento 2 uses a database pattern called Entity-Attribute-Value, or EAV, to store product, category, customer, and order data. In a traditional database table, every possible field gets its own column. EAV works differently: it splits data across multiple tables organized by data type.
The three building blocks are straightforward. An entity is the thing you’re describing (a product, a customer). An attribute is a property of that entity (product name, price, color). A value is the actual data stored for that attribute on a specific entity. Instead of one wide table with a column for every possible product attribute, Magento stores integer values in one table, text values in another, decimal values in a third, and so on.
This design makes it easy to add new attributes without altering the database schema. If you sell clothing and need a “fabric type” attribute, you create it through the admin panel or code, and Magento adds rows to existing tables rather than adding a new column. For stores with thousands of configurable attributes across different product types, this flexibility is essential.
The tradeoff is query complexity. Retrieving a single product’s full set of attributes means joining data from several tables, which slows down read operations. Magento addresses this with flat tables, which are pre-built, denormalized copies of the EAV data. A flat table like catalog_product_flat consolidates all attribute values for each product into a single row. Magento rebuilds these flat tables during a process called indexing, which you can trigger manually from the command line or schedule to run automatically. Storefront queries then read from the fast flat table instead of joining multiple EAV tables. The cost is that reindexing large catalogs can take significant time, especially after bulk product updates.
Request Flow and Page Rendering
When a shopper visits your store, their browser sends a request to the web server, which passes it to Magento’s PHP application. Magento’s routing system matches the URL to a specific module and controller. The controller gathers the data needed for the page (product details, category listings, cart contents), then hands that data to the layout and template system for rendering.
Magento’s layout system uses XML files to define which blocks of content appear on each page and in what order. A block might be the main product image, the price display, the “add to cart” button, or a related-products carousel. Each block is backed by a PHP class that prepares its data and a template file (written in PHTML, a mix of PHP and HTML) that produces the final markup. This separation lets you rearrange, add, or remove page elements through XML configuration without touching the template files themselves.
The default storefront theme, called Luma, ships with every Magento 2 installation. Luma uses a combination of RequireJS for JavaScript loading and Knockout.js for dynamic UI elements like the minicart and checkout page. While functional, Luma is heavy. A typical Luma page makes roughly 230 HTTP requests and transfers around 3 MB of uncompressed data, which can hurt page speed scores.
Alternatives to the Default Theme
Performance concerns have driven the community toward lighter frontend options. Hyvä is the most widely adopted alternative. It rebuilds the entire storefront using Alpine.js and Tailwind CSS while still using Magento’s native PHP templating system. The result is dramatic: roughly 5 page requests and 0.4 MB of uncompressed data per page load, a 98% reduction in requests compared to Luma. Because Hyvä stays within Magento’s server-side rendering model, it doesn’t require a separate frontend application or API layer.
For stores that want a fully decoupled frontend, Magento 2 supports headless commerce through its REST and GraphQL APIs. In a headless setup, the storefront is a separate application (often built with React or Vue.js) that fetches product data, manages the cart, and processes checkout entirely through API calls. The Magento backend handles business logic, inventory, and order management while the frontend team has complete control over the shopping experience. This approach adds architectural complexity but gives maximum flexibility for brands that need a highly custom or multi-channel storefront.
Caching and Performance Layers
Magento 2 is a large application, and without caching, page load times would be unacceptable for real shoppers. The platform uses multiple caching layers that each solve a different problem.
At the application level, Magento caches compiled configuration, layout XML, block output, and full pages. By default this cache lives on disk, but production stores almost always use an in-memory key-value store. Recent versions support Valkey (version 8) and Redis (version 7.2) for this purpose. Storing cache data in memory instead of on disk cuts response times significantly.
In front of the web server, Varnish acts as a reverse proxy cache. When a page is cacheable (most catalog and CMS pages are), Varnish serves it directly from memory without ever touching PHP. This lets a single server handle thousands of concurrent visitors on cached pages. Magento ships with a Varnish configuration file tailored to its caching rules, so setup is largely a matter of deploying Varnish and pointing it at your Magento instance.
For search functionality, Magento 2 relies on a dedicated search engine rather than running queries directly against the database. Current versions use OpenSearch (versions 2.19 or 3, depending on your Magento release). OpenSearch indexes your product catalog and handles faceted search, autocomplete, and relevance ranking far more efficiently than MySQL could on its own.
The Technology Stack
Running Magento 2 requires a specific combination of server software. The platform is built on PHP, and version requirements vary by release. Magento 2.4.8 supports PHP 8.3 and 8.4. The upcoming 2.4.9 beta targets PHP 8.4 and 8.5. Older releases in the 2.4.6 and 2.4.7 lines support PHP 8.1 through 8.3.
For the database, you’ll need MySQL 8.0 or 8.4, or MariaDB 10.11 or 11.4, again depending on your Magento version. Composer manages PHP dependencies and module installation. Nginx or Apache serves as the web server, with Nginx being the more common choice in production. The full stack, then, is Linux, Nginx (or Apache), MySQL/MariaDB, PHP, OpenSearch, Varnish, and Redis/Valkey. Each component needs to match the version matrix for your specific Magento release, so checking compatibility before upgrading any part of the stack saves real headaches.
Admin Panel and Store Management
The Magento 2 admin panel is where merchants manage day-to-day operations. From a single dashboard, you can create and edit products (simple, configurable, grouped, bundled, virtual, and downloadable types), organize categories, set pricing rules and promotions, manage customer accounts, and process orders.
Product attributes, the building blocks of your catalog, are fully customizable. You can create attribute sets for different product types (a “shoes” set might include size and material, while an “electronics” set includes voltage and warranty length) and use those attributes for layered navigation so shoppers can filter search results.
Magento 2 natively supports multiple stores from a single installation. You can run several storefronts with different domains, designs, product catalogs, and currencies, all sharing one admin panel and one database. This multi-store capability is one of the main reasons mid-size and enterprise merchants choose the platform, since it lets them manage regional or brand-specific stores without duplicating infrastructure.
How Extensions Fit In
The Magento Marketplace and independent developers offer thousands of extensions that add functionality the core platform doesn’t include. Payment gateways, advanced shipping calculators, subscription billing, loyalty programs, ERP integrations, and SEO tools are all common extension categories.
Extensions follow the same modular structure as core code. A well-built extension installs through Composer, registers itself as a module, and uses Magento’s plugin (interceptor) system to modify behavior. Plugins let an extension run code before, after, or around any public method in the application without overwriting the original class. This is cleaner than the class-rewrite approach Magento 1 relied on, where two extensions trying to modify the same class would conflict. Conflicts still happen in Magento 2, but the plugin system makes them less frequent and easier to diagnose.
Installing an extension typically involves running a Composer command, enabling the module, running database migrations (if the extension adds or modifies tables), and clearing caches. On a production store, you’d do this in a staging environment first to catch compatibility issues before they reach live shoppers.