Product catalog design in HLD - System Design Guide

Problem Statement

When an e-commerce platform grows, storing all product information in a single database table or service causes slow searches, poor user experience, and difficulty in managing diverse product types. Without a scalable design, adding new product categories or attributes becomes error-prone and costly.

Solution

The product catalog design organizes product data into modular components with flexible schemas, enabling efficient search and easy extension. It separates core product information from category-specific attributes and uses indexing and caching to speed up queries. This design supports multiple product types and scales horizontally as the catalog grows.

Architecture

Product Core

(ID, Name,

→Category Data

↓

Search & Index Layer

↓

API Layer

API Layer

This diagram shows the separation of product core data, category-specific data, and flexible attribute storage, all feeding into a search and indexing layer that supports efficient queries through an API.

Trade-offs

✓ Pros

→

Supports diverse product types with flexible attribute storage.

→

Improves search performance by indexing core and attribute data separately.

→

Eases addition of new categories without schema changes to core tables.

→

Enables horizontal scaling by separating concerns.

✗ Cons

→

Increased complexity in data modeling and query logic.

→

Requires careful synchronization between core and attribute data.

→

Potentially higher latency for complex queries joining multiple tables.

Use when the product catalog has multiple categories with different attributes and the system expects high read traffic with frequent searches and filters.

Avoid if the catalog is small (under a few thousand products) with uniform attributes, where a simple flat schema suffices.

Real World Examples

Amazon

Amazon uses a flexible product catalog design to handle millions of products across thousands of categories, each with unique attributes, enabling fast search and filtering.

Shopify

Shopify supports diverse merchant catalogs by separating core product data from customizable attributes, allowing merchants to define their own product fields.

eBay

eBay manages a large, dynamic catalog with category-specific attributes and uses indexing layers to provide quick search and filtering for buyers.

Alternatives

Monolithic Flat Schema

Stores all product attributes in a single table with many nullable columns.

Use when: Choose when the product catalog is small and attributes are mostly uniform across products.

Document Store Catalog

Uses a NoSQL document database to store each product as a flexible JSON document.

Use when: Choose when product attributes vary widely and schema flexibility is paramount, with less complex relational queries.

Graph-based Catalog

Represents products and attributes as nodes and edges in a graph database.

Use when: Choose when relationships between products, categories, and attributes are complex and require traversal queries.

Summary

Product catalog design separates core product data from flexible category-specific attributes to handle diverse products efficiently.

It uses indexing and modular schemas to enable fast search and easy extension as the catalog grows.

This design balances flexibility and performance, suitable for large-scale e-commerce platforms with varied product types.

Practice

1.

What is the primary purpose of a product catalog in an e-commerce system?

easy

A. To organize products into categories for easy browsing

B. To process payments securely

C. To manage user login sessions

D. To handle shipping and delivery logistics

Solution

1. Step 1: Understand the role of a product catalog

   A product catalog groups products logically so users can browse easily.

2. Step 2: Differentiate from other system components

   Payment, user sessions, and shipping are separate concerns from product organization.

3. Final Answer:

   To organize products into categories for easy browsing -> Option A

4. Quick Check:

   Product catalog = Organize products [OK]

Hint: Catalog = product organization, not payments or shipping [OK]

Common Mistakes:

• Confusing catalog with payment processing
• Mixing catalog with user authentication
• Thinking catalog manages shipping

2.

Which data structure is most suitable to represent categories and subcategories in a product catalog?

A. Array
B. Linked List
C. Tree
D. Hash Map

easy

A. Array

B. Linked List

C. Hash Map

D. Tree

Solution

1. Step 1: Analyze category relationships

   Categories have parent-child relationships, forming a hierarchy.

2. Step 2: Choose data structure for hierarchy

   A tree structure naturally represents hierarchical data with branches and leaves.

3. Final Answer:

   Tree -> Option D

4. Quick Check:

   Hierarchy = Tree [OK]

Hint: Hierarchies = Trees, not flat lists or arrays [OK]

Common Mistakes:

• Using arrays which are flat and unordered
• Choosing linked lists which are linear
• Hash maps don't represent hierarchy well

3.

Consider a product catalog system that uses an inverted index for search. What is the main benefit of using an inverted index?

medium

A. It manages user reviews and ratings

B. It stores product images efficiently

C. It speeds up product search by mapping keywords to product IDs

D. It handles payment transactions securely

Solution

1. Step 1: Understand inverted index purpose

   An inverted index maps keywords to the list of documents or products containing them.

2. Step 2: Apply to product search

   This mapping allows fast lookup of products matching search terms, improving speed.

3. Final Answer:

   It speeds up product search by mapping keywords to product IDs -> Option C

4. Quick Check:

   Inverted index = fast keyword search [OK]

Hint: Inverted index = keyword to product map for fast search [OK]

Common Mistakes:

• Thinking it stores images
• Confusing with user review storage
• Mixing with payment processing

4.

A product catalog system caches product details but users report seeing outdated information. What is the likely cause?

medium

A. Cache invalidation is not handled properly after product updates

B. The database schema is incorrect

C. User authentication is failing

D. The product images are missing

Solution

1. Step 1: Identify caching issue

   Outdated info usually means cache still holds old data after updates.

2. Step 2: Understand cache invalidation

   Proper cache invalidation removes or refreshes cached data when products change.

3. Final Answer:

   Cache invalidation is not handled properly after product updates -> Option A

4. Quick Check:

   Outdated cache = invalidation problem [OK]

Hint: Outdated data? Check cache invalidation first [OK]

Common Mistakes:

• Blaming database schema without evidence
• Confusing with authentication issues
• Assuming missing images cause outdated text

5.

You are designing a product catalog for a global e-commerce platform with millions of products and frequent updates. Which design choice best supports scalability and fast search?

A. Use a distributed NoSQL database with indexing and cache layers
B. Store all products in a single relational database without caching
C. Use flat files to store product data and search sequentially
D. Keep product data only in application memory without persistence

hard

A. Store all products in a single relational database without caching

B. Use a distributed NoSQL database with indexing and cache layers

C. Use flat files to store product data and search sequentially

D. Keep product data only in application memory without persistence

Solution

1. Step 1: Consider scalability needs

   Millions of products and frequent updates require a scalable, distributed system.

2. Step 2: Evaluate design options

   A distributed NoSQL database supports horizontal scaling; indexing enables fast search; caching improves response time.

3. Step 3: Reject unsuitable options

   Single DB limits scale; flat files are slow; in-memory only risks data loss.

4. Final Answer:

   Use a distributed NoSQL database with indexing and cache layers -> Option B

5. Quick Check:

   Scalable + fast search = distributed NoSQL + index + cache [OK]

Hint: Scale needs distributed DB + index + cache, not flat files [OK]

Common Mistakes:

• Choosing single DB without caching for large scale
• Using flat files causing slow search
• Relying on memory only risking data loss