| Scale | Users | Catalog Size | Traffic (Requests/sec) | Storage | Key Changes |
|---|---|---|---|---|---|
| Small | 100 | 10K products | 50 | ~1 GB | Single database instance, simple caching |
| Medium | 10K | 100K products | 5,000 | ~10 GB | Read replicas, distributed cache, basic load balancing |
| Large | 1M | 1M products | 100,000 | ~100 GB | Sharded database, CDN for images, advanced caching |
| Very Large | 100M | 100M+ products | 5,000,000 | ~10 TB+ | Multi-region sharding, microservices, global CDN, asynchronous processing |
Product catalog design in HLD - Scalability & System Analysis
Start learning this pattern below
Jump into concepts and practice - no test required
At small to medium scale, the database is the first bottleneck. It struggles with high read and write queries as users browse and update product info. As traffic grows, a single database instance cannot handle the load, causing slow responses.
- Read Replicas: Add read-only database copies to spread read traffic.
- Caching: Use in-memory caches (like Redis) to store popular product data and reduce database hits.
- Sharding: Split the product catalog across multiple database servers by product ID or category to distribute load.
- CDN: Serve product images and static content via Content Delivery Networks to reduce server bandwidth and latency.
- Horizontal Scaling: Add more application servers behind load balancers to handle increased user requests.
- Asynchronous Processing: Use background jobs for heavy tasks like indexing or bulk updates to keep the system responsive.
- At 1M users with 100,000 requests/sec, assuming 50% cache hit rate, database handles ~50,000 QPS.
- Each product record ~1 KB, 1M products = ~1 GB raw data; with indexes and metadata, ~10-20 GB storage needed.
- Images stored on CDN reduce bandwidth on origin servers; typical image size ~100 KB, 100,000 views/sec = ~10 GB/s bandwidth if uncached.
- Network bandwidth and storage costs grow significantly at large scale; plan for multi-region deployments.
Start by clarifying scale and requirements. Discuss current bottlenecks and how they evolve with growth. Propose incremental solutions: caching, read replicas, sharding, CDN. Explain trade-offs and how each solution fits the scale. Use real numbers to justify choices.
Your database handles 1000 QPS. Traffic grows 10x to 10,000 QPS. What do you do first?
Answer: Add read replicas and implement caching to reduce load on the primary database before considering sharding or more complex solutions.
Practice
What is the primary purpose of a product catalog in an e-commerce system?
Solution
Step 1: Understand the role of a product catalog
A product catalog groups products logically so users can browse easily.Step 2: Differentiate from other system components
Payment, user sessions, and shipping are separate concerns from product organization.Final Answer:
To organize products into categories for easy browsing -> Option AQuick Check:
Product catalog = Organize products [OK]
- Confusing catalog with payment processing
- Mixing catalog with user authentication
- Thinking catalog manages shipping
Which data structure is most suitable to represent categories and subcategories in a product catalog?
A. ArrayB. Linked ListC. TreeD. Hash Map
Solution
Step 1: Analyze category relationships
Categories have parent-child relationships, forming a hierarchy.Step 2: Choose data structure for hierarchy
A tree structure naturally represents hierarchical data with branches and leaves.Final Answer:
Tree -> Option DQuick Check:
Hierarchy = Tree [OK]
- Using arrays which are flat and unordered
- Choosing linked lists which are linear
- Hash maps don't represent hierarchy well
Consider a product catalog system that uses an inverted index for search. What is the main benefit of using an inverted index?
Solution
Step 1: Understand inverted index purpose
An inverted index maps keywords to the list of documents or products containing them.Step 2: Apply to product search
This mapping allows fast lookup of products matching search terms, improving speed.Final Answer:
It speeds up product search by mapping keywords to product IDs -> Option CQuick Check:
Inverted index = fast keyword search [OK]
- Thinking it stores images
- Confusing with user review storage
- Mixing with payment processing
A product catalog system caches product details but users report seeing outdated information. What is the likely cause?
Solution
Step 1: Identify caching issue
Outdated info usually means cache still holds old data after updates.Step 2: Understand cache invalidation
Proper cache invalidation removes or refreshes cached data when products change.Final Answer:
Cache invalidation is not handled properly after product updates -> Option AQuick Check:
Outdated cache = invalidation problem [OK]
- Blaming database schema without evidence
- Confusing with authentication issues
- Assuming missing images cause outdated text
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 layersB. Store all products in a single relational database without cachingC. Use flat files to store product data and search sequentiallyD. Keep product data only in application memory without persistence
Solution
Step 1: Consider scalability needs
Millions of products and frequent updates require a scalable, distributed system.Step 2: Evaluate design options
A distributed NoSQL database supports horizontal scaling; indexing enables fast search; caching improves response time.Step 3: Reject unsuitable options
Single DB limits scale; flat files are slow; in-memory only risks data loss.Final Answer:
Use a distributed NoSQL database with indexing and cache layers -> Option BQuick Check:
Scalable + fast search = distributed NoSQL + index + cache [OK]
- Choosing single DB without caching for large scale
- Using flat files causing slow search
- Relying on memory only risking data loss
