Design a Parts Compatibility Feature for an E-commerce Site — System Design Interview Practice

Interview prompt

Design a parts compatibility feature for an e-commerce site so a shopper can identify their vehicle, device, or existing product and confidently determine which catalog items fit before adding them to a cart.

• Separate catalog data quality and fitment modeling from the low-latency shopper lookup path.
• Model aliases, normalized product contexts, positive fitment, exclusions, and effective-dated rules explicitly.
• Use a versioned read index and explainable results while revalidating compatibility at cart or checkout.
• Handle catalog publication, corrections, stale indexes, merchant workflows, and mismatch feedback asynchronously.

Requirements and scale assumptions

• Let shoppers select or search for a vehicle, device, or existing product and save that context.
• Show compatible, incompatible, and unknown states for a product, with a short reason where possible.
• Filter category/search results by compatibility and carry the selected context into cart and checkout.
• Let catalog operators import, validate, approve, publish, correct, and roll back fitment data.
• Accept mismatch reports and make their source product, context, and catalog version auditable.
• Return common fitment checks within 150 ms at p95 and keep the shopper path available during indexing outages.
• Prevent false-positive compatibility claims; an unknown result must not be presented as guaranteed fit.
• Support replayable, idempotent publication with a visible freshness and index-version signal.
• Protect tenant/catalog permissions, validate untrusted identifiers, and avoid leaking private merchant data.
• Assume 50 million products and 200 million normalized product-context relationships across markets.
• Assume 10 million daily active shoppers, 40 compatibility checks per shopper, and 4,600 average checks/second with 10x peak headroom.
• Assume 2 million fitment changes per day, processed in batches; read traffic is roughly 20:1 over writes.
• Assume a context is a bounded identifier set such as vehicle year/make/model/trim, not arbitrary free text.

• Peak lookup rate: 46K checks/s — 10x headroom over the estimated 4.6K average checks/s.
• Lookup target: 150 ms p95 — Includes normalization, cache/index access, and response formatting.
• Fitment corpus: 200M relations — A purpose-built index avoids scanning the transactional catalog.
• Publication freshness: < 5 min — Target for approved changes to reach the query index under normal load.

Key entities

• CompatibilityContextcontextId, productType, make, model, year, deviceVersion, normalizedAt

  Normalized shopper or installed-product context.

• CompatibilityRuleruleId, catalogVersion, contextPredicate, partIds, confidence, status

  Versioned rule or fitment mapping.

• FitmentResultcontextHash, partId, result, ruleVersion, explanations, computedAt

  Cacheable result with rule and catalog versions.

• CatalogVersioncatalogId, version, publishedAt, effectiveAt, sourceHash, status

  Atomic publication boundary for product and fitment data.

Data flow

1. 1. Normalize shopper contextThe service resolves make/model/year, device versions, aliases, and missing dimensions into a canonical context with validation errors.
2. 2. Evaluate fitmentThe query path checks a context-hash cache and purpose-built index, then returns compatible parts with rule explanations and catalog version.
3. 3. Publish catalog and rulesCatalog admins validate rules, detect conflicts, and publish an immutable version before index workers receive a change event.
4. 4. Refresh compatibility indexesWorkers recompute affected contexts or rule partitions asynchronously and expose index freshness and publication watermarks.
5. 5. Protect checkout correctnessThe cart or order boundary rechecks fitment against the current catalog/rule version so a stale recommendation cannot create an invalid purchase.

Deep dives and trade-offs

• Rule versioning and fitment correctnessFor the parts compatibility and fitment feature, a fitment answer must identify the normalized context and catalog/rule versions that produced it. Design for the failure case where ambiguous aliases, conflicting rules, catalog changes, and stale caches must not create unsafe recommendations; keep retries, versions, and repair state explicit. Expose freshness, version, lineage, or audit metadata so operators and clients can distinguish current, pending, and degraded state.
• Context normalization and cache keysFor the parts compatibility and fitment feature, a fitment answer must identify the normalized context and catalog/rule versions that produced it. Keep this concern off unrelated request paths and partition it by the parts compatibility and fitment feature access key. Expose freshness, version, lineage, or audit metadata so operators and clients can distinguish current, pending, and degraded state.
• Catalog publication and checkout rechecksFor the parts compatibility and fitment feature, a fitment answer must identify the normalized context and catalog/rule versions that produced it. Keep this concern off unrelated request paths and partition it by the parts compatibility and fitment feature access key. Expose freshness, version, lineage, or audit metadata so operators and clients can distinguish current, pending, and degraded state.
• Rule engine versus precomputed fitment indexUse precomputed/indexed results for high-volume reads and a rule engine for publication validation and bounded misses. Evaluating every rule on the shopper path is predictable only at small catalog scale.
• Cache speed versus vehicle/device changesKey caches by normalized context and catalog version with targeted invalidation on publication. A context-insensitive cache can return a plausible but incorrect part.
• Strict fitment versus useful uncertaintyReturn compatible, incompatible, and unknown states with explanations instead of guessing when data is incomplete. Overly strict unknown handling reduces recall; guessing can cause returns or safety issues.