Product Catalog Service: Scaling SKUs Without Explosion
Imagine an e-commerce platform managing 50 million product variants across hundreds of categories. A naive approach would create a database entry for every combination of size, color, and style, quickly becoming unmanageable. The real challenge isn't storing products, it's organizing them intelligently so you can scale, search, and update efficiently without drowning in redundant data.
Architecture Overview
A production-grade product catalog service separates concerns into distinct layers. At the core, you have a product entity that represents the logical item (a t-shirt, for example), which connects to a variant management system that handles the dimensional attributes (sizes, colors, materials). This separation is critical because it prevents data duplication while maintaining query flexibility.
The architecture typically includes several key components working in concert. A catalog service API handles CRUD operations and search queries, routing requests to either a relational database for structured product metadata or a search engine like Elasticsearch for faceted filtering across millions of SKUs. A separate variant service manages the combinatorial explosion, storing variant definitions and their availability separately from base product information. Behind the scenes, a message queue handles bulk import operations asynchronously, preventing the API from becoming a bottleneck during large data ingestion events.
Cache layers sit at multiple levels, from Redis caching frequently accessed product details to CDN-distributed static content like images and descriptions. A separate attributes service catalogs all possible attribute types and values (sizes available, color codes, material compositions), making bulk imports idempotent and preventing invalid variant combinations from ever entering the system. This design ensures that even with millions of SKUs, your system remains responsive and maintainable.
Design Insight: The Variant Strategy
The trick to handling product variants without creating separate entries lies in normalizing variants as a first-class data structure. Rather than storing individual combinations as products, you store a base product record with metadata (name, description, images), then maintain a separate variants table that references that product along with its attribute selections (size: L, color: blue, quantity: 1000). This approach is similar to what you'd see in InfraSketch's visual representations of normalized schemas.
When a customer searches for "blue t-shirts in size medium," your system queries the base products table for matches, then joins with the variants table to filter by specific attributes. You can index these attributes separately, enabling fast faceted searches across dimensions. Bulk imports leverage this structure beautifully, too, since uploading a CSV with variant rows is infinitely more efficient than creating millions of individual product records. Attributes themselves are often cached or stored in a dedicated service, allowing you to validate and enrich variants in real-time without hitting your main product database.
Watch the Full Design Process
See how this architecture comes together in real-time. The design process reveals the tradeoffs between normalization and query performance, how caching strategies evolve as traffic scales, and why separating variant management from product management prevents architectural headaches down the road.
Try It Yourself
Building a catalog service in your head is one thing, but sketching it out forces you to think through real constraints. Head over to InfraSketch and describe your system in plain English. In seconds, you'll have a professional architecture diagram, complete with a design document.
Whether you're tackling Day 19 of your own system design journey or scaling your first e-commerce platform, visualizing these decisions early prevents costly refactors later.
Top comments (0)