Product catalog design in HLD - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Architecture

intermediate

Designing a scalable product catalog architecture

You need to design a product catalog system that can handle millions of products and thousands of concurrent users. Which architectural approach best supports scalability and fast product search?

A Use a monolithic database with vertical scaling and cache all product data in memory.

B Use a relational database with heavy normalization and rely solely on SQL queries for search.

C Store all product data in flat files on a single server and use periodic batch processing for search indexing.

D Use a distributed NoSQL database with sharding and integrate a dedicated search engine like Elasticsearch.

💡 Hint

Think about how to handle large data volumes and fast search queries efficiently.

Option D uses a distributed NoSQL database that can scale horizontally and a search engine optimized for fast queries, making it the best choice for scalability and performance.

❓ scaling

intermediate

Estimating capacity for product catalog traffic

Your product catalog expects 10,000 requests per second at peak. Each request reads product details averaging 5 KB. What is the approximate network bandwidth needed to handle this load?

A 500 Mbps

B 400 Mbps

C 800 Mbps

D 50 Mbps

💡 Hint

Calculate bandwidth as requests per second multiplied by data size per request, then convert to Mbps.

10,000 requests/sec * 5 KB = 50,000 KB/sec = 50 MB/sec. 50 MB/sec * 8 = 400 Mbps. Considering overhead, 500 Mbps is a safe estimate.

❓ tradeoff

advanced

Choosing between SQL and NoSQL for product catalog

Which tradeoff is most accurate when deciding between SQL and NoSQL databases for a product catalog with complex relationships and frequent updates?

A NoSQL always provides better performance and consistency than SQL for all workloads.

B SQL offers strong consistency and complex queries but may scale less easily; NoSQL scales well but may sacrifice consistency and complex joins.

C SQL databases cannot handle product catalogs with millions of products efficiently.

D NoSQL databases require no schema design and are always easier to maintain.

💡 Hint

Consider consistency, query complexity, and scalability tradeoffs.

SQL databases provide ACID transactions and complex joins but can be harder to scale horizontally. NoSQL databases scale easily but often relax consistency and lack complex join support.

🧠 Conceptual

advanced

Handling product attribute variability in catalog design

Products have widely varying attributes (e.g., electronics vs. clothing). Which design approach best supports flexible attribute storage without schema changes?

A Use a fixed relational schema with columns for all possible attributes, leaving many nulls.

B Create separate tables for each product category with fixed attributes.

C Use a document-oriented NoSQL database storing attributes as flexible key-value pairs.

D Store all attributes as a single JSON string in a relational text column without indexing.

💡 Hint

Think about flexibility and ease of adding new attributes.

Document-oriented NoSQL databases allow storing flexible attributes as key-value pairs, enabling easy schema evolution without downtime.

❓ component

expert

Designing a product catalog update workflow

Which component sequence best ensures consistent product updates with minimal downtime and supports rollback in case of errors?

A 1, 2, 3, 4

B 2, 1, 3, 4

C 1, 3, 2, 4

D 3, 1, 2, 4

💡 Hint

Consider the logical order for safe updates and testing before production deployment.

First validate data, then write to staging, test on staging, and finally promote to production to ensure consistency and rollback capability.

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