All system design challenges
#44 Graph Relations/Metadata

eCommerce Compatibility

Answer "does this part fit my device?" for millions of products, where compatibility is a web of relationships and rules.

Asked at Amazon

What is being asked

An online shop sells parts and accessories. Design the system that knows which products work with which, shows only compatible items for a chosen device or vehicle, and warns about incompatible items in the basket.

Requirements

Functional

  • Store compatibility between products and models, with conditions such as year or variant.
  • "Shop for my model": filter search to compatible products.
  • Check a basket for conflicts.

Non-functional

  • Hundreds of millions of relationships.
  • Read-heavy; answers in milliseconds as part of search.
  • Data arrives from many sellers and is often wrong or incomplete.

Design

Seller feeds /catalogue teamIngestion + validationCompatibility graphstoreFitment index builderSearch index withfitment attributesCompatibility cacheSearch + product pageAPIs
Boxes are services; rounded shapes are data stores and queues.
  1. Model the data as a graph: nodes are products and models; edges say "fits", with attributes for conditions.
  2. Models form a hierarchy: brand, model, generation, variant. A product that fits the whole generation has one edge to the generation node.
  3. An offline builder expands these relationships and writes, for each product, the list of model ids it fits into the search index.
  4. "Shop for my model" then becomes an ordinary filter in search: products whose fitment list contains this model id.
  5. The basket check reads a cache of pairwise rules for the items present.

Key decisions and trade-offs

  • Precompute for reads. Traversing a graph on every search is too slow. Flatten the common question into an indexed attribute and keep the graph for maintenance and unusual queries.
  • Edges at the highest valid level. Attaching to a generation, not to each variant, cuts the edge count and makes corrections apply everywhere at once.
  • Relational or graph database. Two tables with good indexes handle direct lookups. A graph database earns its place when questions chain several hops, such as "parts that fit anything this adapter fits".
  • Data quality is the hard part: conflicting seller claims are resolved by trusting manufacturer data first and tracking returns for "did not fit".

Follow-up questions

  • How do you update the index when one rule changes for a whole product family?
  • How would you express "fits only with adapter X"?
  • How do you measure and improve the accuracy of fitment data?
  • What would you show when compatibility is unknown?
Log in to tick off the challenges you have worked through. Log in