Product & SKU Architecture: Structured Configuration System
This article explains how we use a structured SKU system to manage thousands of product configurations.
The Problem: Combinatorial Explosion
A configurable product has many options:
- 17 chassis types × 17 processors × 8 RAM sizes × 19 storage sizes × 6 WiFi options × 9 OS options = 2,372,112 possible configurations
Managing each configuration manually is impossible:
-
2,372,112 product descriptions to write
-
2,372,112 price calculations to maintain
-
2,372,112 inventory records to track
-
2,372,112 product pages to create
We need a system that generates configurations dynamically.
The Solution: SKU-Based Architecture
We use a hyphen-separated SKU structure where each segment represents a component:
Format: Chassis-Board-RAM-Flash-Adapter-WiFi-OS-Accessories
Example: Treo-97-8-512-65-ax200-W11P-KM
From this SKU, we can:
-
Extract features (processor, RAM, storage)
-
Calculate price (sum of component costs)
-
Generate description (combine component names)
-
Check stock (verify all components available)
Single Source of Truth: productdb
The product database (productdb.json) is the single source of truth for all product information:
-
Format: JSON with categories as top-level keys
-
Categories: Chassis, Board, RAM, Flash, Adapter, WiFi BT, OS, Accessories, Component, Custom
Productdb Structure
Each product has:
-
PartID: Unique identifier (e.g., "Treo", "97", "8")
-
internal: Internal name for employees
-
external: External name for customers
-
class: Product class for compatibility rules
-
allows: Constraints on compatible parts
-
provides: Features provided by this part
-
weight: Weight in grams
-
constituents: For composite parts, list of sub-components
Example Productdb Entry
Productdb entries include chassis, board, RAM, flash, adapter, WiFi BT, OS, and accessories with their specifications.
SKU Structure
SKUs are hyphen-separated strings of part IDs:
-
Format:
{Chassis}-{Board}-{RAM}-{Flash}-{Adapter}-{WiFi BT}-{OS}-{Accessories} -
Example:
Treo-97-8-512-65-ax200-W11P-KM -
Length: Always 8 parts (some may be empty for optional categories)
SKU Parsing
The SKU is parsed using part_sequence which defines the order of categories.
Feature Extraction
Features are extracted from productdb using find_features():
- Start with part: Get the part from productdb
- Add provides: Copy all features from
providesfield - Process constituents: Recursively add features from sub-components
- Multiply numeric values: For quantities (e.g., weight, RAM)
Feature Aggregation
For a complete SKU, features from all parts are aggregated. The aggregation process combines features from all parts in the SKU.
Feature Sequence
feature_sequence defines how features are displayed:
-
Key: Feature name (e.g., "Processor Model", "Screen Size")
-
Value: Dict with
UnitandHeading -
Headings: Processing, Display, Audio, Connectivity, Networking, Power, Environmental, Physical, Accessories, Operating System
Feature Sequence
feature_sequence defines how features are displayed with their units and headings.
Facets for Filtering
FACETS_FOR_FILTERING is dynamically generated from feature_sequence:
-
Excludes: OS Features, Dimensions, Weight, Cache
-
Groups by heading: Processing, Display, Audio, etc.
-
Used for: Query page filters, product search
Filter Facets Structure
FACETS_FOR_FILTERING groups features by heading for query page filters.
Feature Tables
Feature tables are generated from product_features():
- Group by heading: Processing, Display, etc.
- Format values: Add units where applicable
- Display in 2-column layout: Balanced for product pages
Feature Table Example
| Processing | |
|---|---|
| Processor Model | Intel i5-12400 |
| Cores | 6 |
| Max Frequency | 4.4 GHz |
| Main Memory | 16 GB |
| Display | |
|---|---|
| Screen Size | 21.5 inch |
| Resolution | 1920 × 1080 |
| Brightness | 250 nits |
Cross-References
-
Product Pages & Datasheets - How product information is assembled for product pages
-
Query Page Generation - How search queries use features for filtering
-
Search Service Architecture - How features are used in search filtering
-
Translation System - How product features are translated
External Links
-
PynamoDB Documentation - DynamoDB ORM used for product data
-
Flask Documentation - Web framework for the application
-
JSON.org - JSON format specification
Summary
The product & SKU architecture provides:
-
Single source of truth: productdb.json for all product information
-
Feature extraction: Automatic feature aggregation from parts
-
Filtering: FACETS_FOR_FILTERING for query page filters
-
Feature tables: Grouped features for product pages
-
SKU parsing: Hyphen-separated part IDs for product composition