Product catalog design in HLD - Scalability & System Analysis

Scalability Analysis - Product catalog design

Growth Table: Product Catalog Design

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

First Bottleneck

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.

Scaling Solutions

• 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.

Back-of-Envelope Cost Analysis

• 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.

Interview Tip

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.

Self Check

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.

Key Result

The product catalog design first hits database bottlenecks as user traffic and catalog size grow; scaling requires caching, read replicas, and sharding combined with CDN and horizontal scaling to maintain performance.