Designing Category-Agnostic Product Architectures

How do you store computer hardware in a database?

A laptop has a CPU speed, RAM slots, screen refresh rate, and battery watt-hours.
A mechanical keyboard has switch types, keycap profiles, polling rates, and RGB modes.
A CCTV surveillance camera has sensor focal length, night vision distance, and IP weatherproof ratings.

When I started designing the catalog schema for CIVA, the naive approach was tempting: create a laptop_specs table, a keyboard_specs table, and a camera_specs table.

That is a fast path to database maintenance hell.

The Dynamic Specification Model

Every hardware category in our store is just a tree of named technical attributes with typed values and unit labels.

Instead of hardcoding column names into the schema, we separated the catalog into three polymorphic layers:

Attribute Definitions (Attribute): Global technical keys like Socket Type, Frequency, or Storage Capacity, along with their data type (text, number, select, boolean) and unit (GHz, GB, Watts).
Category Blueprints (Category): Associates which attributes are required, optional, or filterable for that category.
Product Instances (Product): Stores clean key-value pairs that reference the global definitions:

{
  "name": "ThinkPad T14 Gen 5",
  "category": "laptops_cat_id",
  "specifications": [
    { "attribute": "cpu_model_id", "value": "AMD Ryzen 7 PRO 8840U" },
    { "attribute": "ram_capacity_id", "value": "32", "unit": "GB" },
    { "attribute": "display_refresh_id", "value": "120", "unit": "Hz" }
  ]
}

The Realization: Filter Indexes Stay Lightning Fast

The biggest concern with polymorphic or key-value data models is query performance: how do you let users filter for "Laptops with ≥ 32GB RAM and 120Hz displays" without scanning millions of subdocuments?

By maintaining a compound multikey index on specifications.attribute and specifications.value, MongoDB resolves faceted filtering directly from RAM indexes in under 4ms.

// Compound multikey index for instant faceted queries
productSchema.index({ category: 1, "specifications.attribute": 1, "specifications.value": 1 });

The Takeaway

Good database architecture accommodates business growth without requiring schema migrations.

When store managers want to add 3D printers, server racks, or custom soldering kits tomorrow, they configure the blueprint in the admin panel. The database schema doesn't change by a single line of code.