Design Instacart product catalogue

Problem Statement

Design a large-scale product catalogue platform that aggregates grocery and household items from multiple retailers and lets customers browse, filter, and search products within their chosen store. The system must handle millions of SKUs across thousands of store locations, where each store carries its own prices, stock levels, and product assortment that change throughout the day.

The core challenges include maintaining a hierarchical category taxonomy that works across diverse retailers, keeping product data synchronized in near real-time as prices and inventory fluctuate, and delivering sub-second browsing experiences despite the massive dataset. Category pages are accessed far more frequently than products are updated, creating a read-heavy traffic pattern that demands aggressive caching and indexing. At the same time, users must always see accurate information scoped to their specific store to prevent checkout failures and eroded trust.

Key Requirements

Functional

• Location-scoped browsing -- Users select a store and navigate a hierarchical category tree (for example, Produce then Fruits then Organic Apples) to discover products available at that location
• Multi-faceted filtering and sorting -- Users apply simultaneous filters such as brand, dietary tags, price range, and ratings, and sort results by price, popularity, or current deals
• Accurate product details -- Display the current price, stock availability, packaging options, nutritional information, and images for each item at the selected store
• Smooth pagination -- Support infinite-scroll pagination through categories with thousands of items while maintaining stable result ordering

Non-Functional

• Scalability -- Serve 50 million daily active users browsing over 100 million products across 10,000-plus store locations with traffic peaks during evening hours
• Reliability -- Maintain 99.95 percent uptime for browse and search; degrade gracefully by showing cached data if real-time inventory updates are temporarily unavailable
• Latency -- Category page loads under 300 ms at p95, search results under 500 ms, and sub-50 ms cache hits for popular pages
• Consistency -- Eventual consistency acceptable for inventory updates within a 5-to-15-minute window, but price changes must propagate within 2 minutes to prevent checkout discrepancies

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Data Modeling and Category Taxonomy

The hierarchical structure of categories and how you represent products with store-specific attributes is fundamental. A poor model leads to expensive queries and difficult maintenance.

Hints to consider:

• Separate shared product information (brand, description, images) from location-specific data (price, inventory count) to avoid duplication
• Represent product variants (different sizes, organic versus conventional) with a parent-variant model that shares core attributes
• Design the category hierarchy to support both rigid navigation paths and flexible cross-category discovery such as all gluten-free items
• Plan how each retailer's proprietary taxonomy maps to your canonical category structure

2. Multi-Tier Caching for Read-Heavy Traffic

Category pages see millions of daily hits, but underlying data changes frequently. Your caching layers determine whether the system stays fast and cost-effective.

Hints to consider:

• Layer caching across CDN for static assets, application-level Redis cache for personalized pages, and database query cache, each with TTLs tuned to data volatility
• Cache complete rendered category pages for common filter and sort combinations; cache individual product objects for less frequent queries
• Warm caches for predictable traffic patterns and implement fine-grained invalidation that avoids flushing entire regions
• Address the cold-start problem when users switch stores or browse uncommon category combinations

3. Near-Real-Time Price and Inventory Synchronization

Retailers push updates through varying mechanisms and frequencies. Stale prices lead to abandoned carts and customer dissatisfaction.

Hints to consider:

• Build an ingestion pipeline that normalizes heterogeneous data formats and handles different update cadences across retailers
• Apply partial index updates when a subset of products changes rather than rebuilding the entire index
• Propagate changes through an event stream so caching layers and search indices receive targeted invalidations
• Handle conflicting updates such as a price change arriving while a customer is adding the item to their cart

4. Search and Filter Performance at Scale

Users expect instant results when applying multiple filters to categories with tens of thousands of products. Poorly designed indexing makes this impossible.

Hints to consider:

• Create denormalized search documents that embed commonly filtered attributes directly to eliminate joins at query time
• Partition the search index by store or region to keep working sets manageable and enable parallel query execution
• Pre-compute facet counts for popular filter combinations instead of recalculating on every request
• Use cursor-based or keyset pagination to maintain result consistency as users scroll and underlying data changes

Suggested Approach

Step 1: Clarify Requirements

Start by understanding the scope. Ask about the number of retailers, products, and stores in the system. Confirm whether all stores from a retailer share the same catalogue or each has a unique assortment. Determine acceptable staleness for different data types. Clarify whether the system must support personalization or only anonymous browsing. Understand peak load patterns and geographic distribution.

Step 2: High-Level Architecture

Sketch the major components: an ingestion layer that normalizes retailer feeds into a canonical product model, a search and indexing service (Elasticsearch or similar) that powers category browsing and filtering, a multi-tier caching layer with Redis for application-level caching and a CDN for static content, and API servers that orchestrate requests. Include a separate product information service for master data distinct from store-specific pricing and inventory. Show event streams via Kafka that propagate updates from ingestion to search indices and caches. Illustrate both the read path (user browses a category) and the write path (retailer updates prices).

Step 3: Deep Dive on Data Model and Search Index

Walk through the search document structure in detail. Each document contains product ID, name, brand, a category-path array enabling ancestor queries, store-specific nested objects with price and availability, and pre-computed filter attributes. Explain the partitioning strategy, whether sharding by store location or geographic region to keep hot data co-located. Show how category page queries translate into index scans with filters, and distinguish the common case (popular category, frequent filters) from long-tail queries. Address why cursor-based pagination outperforms offset-based for large result sets.

Step 4: Address Secondary Concerns

Cover cache invalidation: when a price update arrives, identify which cache keys need invalidation and how to prevent thundering herd problems. Discuss monitoring: track cache hit rates, query latencies by category depth, and staleness metrics. Address failure scenarios: what happens if the search cluster degrades (fall back to database queries with reduced filter support) or retailer feeds stop updating (show a last-known-good timestamp). Mention consistency around users adding items to cart while prices update, and how to handle version conflicts. Touch on how the system would evolve to support personalized ranking or real-time deal notifications.