Design the Product Catalog for a Multi-Store Grocery Delivery Marketplace

Quick Overview

A senior system design prompt reported from a RapidSOS loop: design the product catalog for a multi-store grocery delivery marketplace like Instacart. It tests modeling shared products versus per-store prices and availability, ingesting messy retailer feeds, store-scoped browse and search, caching, freshness and checkout consistency.

Design the Product Catalog for a Multi-Store Grocery Delivery Marketplace

Company: RapidSOS

Role: Software Engineer

Category: System Design

Difficulty: medium

Interview Round: Other

Design the product catalog for a grocery delivery marketplace such as Instacart. A customer chooses a nearby store, browses its aisles, searches for items and fills a cart; a shopper then picks the order in the physical store. Every product listing, search result and item page the customer sees is served from the catalog, and the cart and checkout rely on it for prices. Assume the standard shape of this kind of marketplace: - Many independent retailers, each with many store locations. - The same physical product, such as one brand and size of milk, is sold by many retailers, but its price, availability and promotions differ from store to store. - Retailers send their catalogs, prices and inventory through bulk files and incremental updates, on their own schedules and with uneven data quality. Design the system that ingests this data and serves it to customers. ```hint Separate data by how fast it changes Product descriptions, store prices and shelf availability change on very different schedules and are shared by very different numbers of stores; ask which of them belong in the same record. ``` ```hint Follow one update end to end Trace a single price change from the moment a retailer sends it to the moment a customer sees it in a search result and at checkout, and note where it could be delayed, lost or applied out of order. ``` ### Constraints and Clarifications - The prompt gives no scale, freshness or latency numbers; propose them and keep the design consistent with them. - Search ranking quality, recommendations, payments and shopper routing are out of scope except for what they need from the catalog. - In-store stock is never known exactly; the catalog only knows what retailers report. ### Clarifying Questions - Do customers only browse one selected store at a time, or do we also need cross-store views, such as comparing one product's price at several retailers? - How fresh must prices and availability be when shown, and if a price changes between adding to cart and checkout, which price applies? - Do retailers supply standard product identifiers such as barcodes for every item, or must we match their items to shared products ourselves? - Are there items priced by weight, such as produce, or with variants such as sizes and flavors? - Roughly how many retailers, stores and items per store should we plan for? ### What a Strong Answer Covers - Functional and non-functional requirements with stated scale, read-to-write ratio and freshness targets - A data model that separates shared product information from per-store offers - Ingestion of heterogeneous retailer data: validation, normalization, product matching and protection against bad feeds - A low-latency, store-scoped read path for browse, search and item pages, including caching and how indexes stay current - Consistency between what customers browse and the price and availability used at checkout - Scaling, failure handling and observability on both the ingestion and the serving side ### Follow-up Questions - A retailer's feed mistakenly sets thousands of prices to zero. How does your system catch it before customers see it? - How would you add per-store promotions that must start and end at exact times? - Customers often order items shown as available that the shopper cannot find. How would you use fulfilment data to improve availability? - How would you onboard a new retailer whose items have no barcodes?

Overview: A senior system design prompt reported from a RapidSOS loop: design the product catalog for a multi-store grocery delivery marketplace like Instacart. It tests modeling shared products versus per-store prices and availability, ingesting messy retailer feeds, store-scoped browse and search, caching, freshness and checkout consistency.

RapidSOS logo
RapidSOS
Feb 7, 2026
mediumSoftware EngineerOtherSystem Design
0
0

Design the product catalog for a grocery delivery marketplace such as Instacart. A customer chooses a nearby store, browses its aisles, searches for items and fills a cart; a shopper then picks the order in the physical store. Every product listing, search result and item page the customer sees is served from the catalog, and the cart and checkout rely on it for prices.

Assume the standard shape of this kind of marketplace:

  • Many independent retailers, each with many store locations.
  • The same physical product, such as one brand and size of milk, is sold by many retailers, but its price, availability and promotions differ from store to store.
  • Retailers send their catalogs, prices and inventory through bulk files and incremental updates, on their own schedules and with uneven data quality.

Design the system that ingests this data and serves it to customers.

Constraints and Clarifications

  • The prompt gives no scale, freshness or latency numbers; propose them and keep the design consistent with them.
  • Search ranking quality, recommendations, payments and shopper routing are out of scope except for what they need from the catalog.
  • In-store stock is never known exactly; the catalog only knows what retailers report.

Clarifying Questions Guidance

  • Do customers only browse one selected store at a time, or do we also need cross-store views, such as comparing one product's price at several retailers?
  • How fresh must prices and availability be when shown, and if a price changes between adding to cart and checkout, which price applies?
  • Do retailers supply standard product identifiers such as barcodes for every item, or must we match their items to shared products ourselves?
  • Are there items priced by weight, such as produce, or with variants such as sizes and flavors?
  • Roughly how many retailers, stores and items per store should we plan for?

What a Strong Answer Covers Guidance

  • Functional and non-functional requirements with stated scale, read-to-write ratio and freshness targets
  • A data model that separates shared product information from per-store offers
  • Ingestion of heterogeneous retailer data: validation, normalization, product matching and protection against bad feeds
  • A low-latency, store-scoped read path for browse, search and item pages, including caching and how indexes stay current
  • Consistency between what customers browse and the price and availability used at checkout
  • Scaling, failure handling and observability on both the ingestion and the serving side

Follow-up Questions Guidance

  • A retailer's feed mistakenly sets thousands of prices to zero. How does your system catch it before customers see it?
  • How would you add per-store promotions that must start and end at exact times?
  • Customers often order items shown as available that the shopper cannot find. How would you use fulfilment data to improve availability?
  • How would you onboard a new retailer whose items have no barcodes?