Design Product Catalog

Problem Statement & Context

A product catalog is the authoritative system of record for everything customers see about items: titles, descriptions, variants, attributes, pricing metadata, media, and availability flags. It is the data backbone that powers search, recommendations, merchandising, and checkout.

At scale the catalog is not a single table — it is a distributed system that ingests data from sellers, suppliers, and internal teams, validates it, normalizes attributes, and serves read-optimized views to millions of shoppers at low latency.

The journeys

• Shopper: browse a category → filter by attributes (brand, size, color) → open PDP with variants → consistent pricing + availability.
• Seller: create a listing with attributes → upload media → publish/bulk-edit → track validation errors + approvals.
• Merchandiser: organize taxonomy → define attribute dictionaries + rules → curate collections → monitor catalog quality.

The load-bearing idea: normalize-on-write, denormalize-for-read, normalize attributes as the quality gate

The catalog's central tension is write flexibility versus read performance: sellers submit messy, free-form data (one types "navy", another "Navy Blue", a third "#000080"), but shoppers need fast, consistent faceted browsing. The resolution is two models bridged by an event stream — a normalized relational write model (products, variants, attributes; integrity constraints; strongly-consistent publish) projected into a denormalized read/search model (eventually consistent, flat documents, fast facets). And the gate between them is attribute normalization: free-form values are mapped to canonical ones at ingest, because if "navy" and "Navy Blue" reach the facet index as distinct values, the color filter fragments and search breaks. Normalize-on-write, denormalize-for-read, with attribute normalization as the data-quality gate — that is the whole design.

Scale anchors

50M monthly shoppers; 20M SKUs × ~5 variants; 200M daily reads; 2M seller updates/day. Read-heavy (~10,000:1 read/write), so the design optimizes the read path hard while keeping writes correct.