A parametric product catalog — the ti.com-style experience where engineers filter thousands of components down to a shortlist by their technical specifications — looks simple from the outside and is anything but underneath. We learned this firsthand building the online technical catalog for CDIL, a semiconductor manufacturer with a broad range of discrete devices. This article is the engineering companion to that case study: a practical look at the architecture decisions that make a parametric catalog fast, scalable, and — the part everyone underestimates — maintainable for years.
The Core Problem: Heterogeneous Products
The defining difficulty is that different product families are described by different attributes. A rectifier diode cares about reverse voltage and forward current; a small-signal transistor cares about gain, collector current, and transition frequency; a voltage regulator cares about output voltage and dropout. There is no single set of columns that fits them all. The instinct to create one giant table with a column for every possible parameter fails fast — it becomes a sparse, unmanageable sprawl of mostly-empty fields, and every new product family means an irreversible schema change.
The Data Model: Parameters as Data
The durable answer is to model parameters as data, not as schema. There are a few proven approaches, each with trade-offs:
- Entity-Attribute-Value (EAV): products, attributes, and values live in separate tables, so any family can have any attributes. Maximally flexible, but queries are more complex and need careful indexing to stay fast.
- Document / JSON columns: store each product's parameters in a JSON column inside a relational database, combining a stable core schema with flexible per-family attributes. Modern databases index JSON well, making this a pragmatic middle ground.
- Per-family tables with a shared registry: each family gets its own typed table, unified by a central parameter registry that drives the UI. Fast and clean, at the cost of more tables to manage.
Whichever you choose, the non-negotiable companion is a parameter registry — a definition of each parameter (name, unit, data type, valid range, which families use it, how it displays). This registry is what lets the same engine render filters, format values, and validate input across every family without hard-coding anything per product.
"The schema should describe how to describe a product — not the product itself. Get that level of abstraction right and the catalog absorbs new product families instead of breaking on them."
— ESS ENN Associates Engineering Team
Search and Filtering: The Faceted Engine
The interaction engineers expect is faceted search: select several attribute filters at once — a voltage range, a package, a polarity — and watch the result set and the available options update instantly, ideally with counts showing how many parts match each remaining choice. Delivering this on a transactional database alone gets painful as data and concurrency grow. The standard, scalable pattern is to project the catalog into a search engine built for filtering — Elasticsearch, OpenSearch, or similar — where facets are pre-computed and multi-parameter queries return in milliseconds. The relational database remains the source of truth; the search index is the read-optimised, denormalised view that powers the UI.
Performance at Scale
Speed is a feature here, not a nicety — an engineer comparing parts abandons a sluggish catalog. The levers that matter: index the facets users actually filter on; denormalise for reads so the catalog view doesn't join half a dozen tables on every request; cache common queries and facet counts; and paginate efficiently so large result sets don't choke the browser or the server. Done together, these keep the experience instant whether the catalog holds hundreds of parts or hundreds of thousands.
The Updatability Imperative
Here is the requirement that quietly decides whether a catalog succeeds: it has to stay current without a developer in the loop. Specifications get revised, datasheets get reissued, families get added. If every change is a code change, the catalog rots within a year. The architecture must therefore separate content from code: the parameter registry and product data are editable through an admin workflow, with validation, audit history, and bulk import (CSV or spreadsheet) so large updates don't require manual entry. The product team owns the catalog; engineering owns the platform. That division is what makes the catalog a living asset rather than a frozen snapshot.
Where AI Fits Now
Modern catalogs increasingly pair the precise parametric filter with a natural-language layer. An engineer can type "a PNP transistor that handles at least 1A and comes in a SOT-23 package" and have an AI assistant translate that into the exact facet filters — combining the convenience of conversation with the rigour of structured search. Built carefully, this is a genuine usability leap, and it is the kind of capability our AI applications team layers onto catalog platforms without compromising the deterministic search underneath.