A consumer electronics catalog means tens or hundreds of thousands of SKUs, each with dozens of attributes: diagonal, resolution, panel type, chipset, memory size, power class, compatibility, dimensions. Shoppers do not search for "TV" - they search for "4K OLED 55-inch with HDMI 2.1 up to 90,000 rubles." The business result affected by the platform is measured simply: what share of visitors move from search to the right product page and add it to the cart without leaving for a competitor because of a slow filter or incomplete results. Below is an open breakdown of what Magento (Adobe Commerce) provides for this kind of task, without tying it to any specific KT.Team project.
Why a large electronics catalog breaks the box product
Magento stores product attributes in an EAV (Entity-Attribute-Value) model. This is flexible - you can add any attribute without changing the database schema - but at scale it becomes a problem: one product's data is spread across many tables, and every catalog, search, or filter query turns into expensive JOINs. Practitioners observe that many platforms start to degrade at 10,000-50,000 SKUs, and adding more attributes directly reduces database throughput and slows the admin panel, sometimes to the point of timeouts (Medium, Yegor Shytikov; Abbacus Technologies).
The conclusion reached by both Adobe's own developers and the community: a Magento catalog with hundreds of thousands of SKUs is realistic, but it requires deliberate indexing work and moving search out of MySQL.
Indexing: a read-only storefront instead of live JOINs
Magento addresses the EAV problem with indexers - they pre-flatten data into denormalized tables that the storefront reads. For large catalogs, several practices from Adobe's official documentation are critical (Indexer Optimization):
- "Update by Schedule" mode is required for indexers that switch tables: the system writes to a replica table and then atomically swaps in the live one, preventing shoppers from seeing a "half-recalculated" catalog.
- Separate read/write tables (for example, `catalog_product_index_price` and its replica) prevent deadlocks during reindexing - the storefront keeps serving data while recalculation runs in the background.
- Batch size is a parameter, not a constant. Adobe gives an example: reducing the `catalog_product_price` batch from 5,000 to 1,000 cut a full reindex of 40,000 products from about 4 hours to under 2 hours.
- Exclude unnecessary combinations Including website x customer group in the index significantly reduces recalculation time, especially with many customer groups and B2B catalogs.
For electronics, this means prices, promotions, and stock for hundreds of thousands of SKUs are updated on schedule, without freezing the storefront during peak traffic hours.
Search and facets: Elasticsearch instead of MySQL
The weak point of plain Magento is layered navigation on MySQL. In a large catalog, filters by brand, diagonal, and price are computed slowly. Moving search and facets to Elasticsearch/OpenSearch delivers a major gain in both speed and UX: filter attributes are indexed and served by the search engine, not the relational database (Folio3, Magento Elasticsearch Guide).
The mature international solution here is the open-source module ElasticSuite from Smile-SA, which layers relevance and facet management on top of Elasticsearch at the level of each attribute (Smile-SA/elasticsuite Wiki):
- Search weight — a numeric attribute weight in ranking: "model name" can be made more important than "case material".
- Coverage rate (default 90%) - a facet is shown only if it covers a significant share of results. This removes the "lens diagonal" filter from laptop results, where it is relevant only for cameras.
- Maximum size a facet and a "show more" button - so the "brand" filter does not display 300 values at once.
- Sort filter values — by number of results, manually, alphabetically, or by relevance; configurable globally and overridable for a specific category.
- Numeric sliders for ranges (price, diagonal, power) with adjustable precision.
This is what "precision in helping the shopper find the right product" means: properly tuned weights and facets surface relevant models at the top and remove noise from filters.
Product comparison and attribute structure
Magento supports comparison out of the box: each attribute can be marked with the "Comparable on Storefront" flag, and the selected characteristics are shown in a comparison table (mgt-commerce). For electronics, where a shopper compares 3-4 models across two dozen parameters, this is a key step toward conversion.
To keep EAV from killing performance, practitioners recommend not one giant attribute set for everything, but a sensible split by product type: TVs and headphones have different attribute sets. Configurable products are used for variations - color, memory size - and are considered the backbone of large electronics catalogs.
An extension approach without forking the core
The mechanisms listed here - indexers, Elasticsearch, ElasticSuite - extend Magento through standard extension points rather than core changes. This follows the engineering principle of minimal tool modification: business logic and integrations are moved into nearby modules and services, relying on mature international standards (Elasticsearch, a ready-made open-source faceting module) instead of custom-built solutions. This keeps the system updatable and transferable - another team can take it over without rewriting it.
Business process takeaway
The main shift is not "configuring filters" but changing how the catalog is managed: the content team treats attributes and attribute sets as a product asset (the completeness and consistency of specifications directly determine facet and comparison quality), while engineers keep search in Elasticsearch and indexing on a schedule. The metric used to validate the result is the share of sessions in which a visitor moved from search or a facet to the correct model page and added it to the cart. If facets are incomplete or search is slow, this can be fixed by adjusting weights, coverage rate, and indexing mode, not by migrating platforms.
