Design Product Comparison

Problem Statement: Product Comparison Platform

Design a product comparison experience — the side-by-side spec sheet you see on Amazon Compare, Best Buy, or CNET. A shopper adds 2–4 SKUs to a compare tray, then views a normalized attribute matrix: price, availability, ratings, and category-specific specs lined up row by row so the products are genuinely comparable.

Why this is a normalization problem, not a CRUD problem

The hard part is not displaying a table — it is aligning heterogeneous catalog attributes into one matrix. Different vendors call the same spec different names ("RAM" / "Memory" / "System Memory"), express the same value in different units ("16GB" / "16384MB"), and leave gaps where they did not provide data. The system must align the attributes, normalize the values, tolerate partial data, and refresh price/stock without reloading the whole page. Attribute normalization is the core hard problem; everything else is plumbing around it.

The mixed-consistency model

A product comparison platform is interesting because it has three different consistency requirements at once. Attribute definitions (the schema: which attributes a category has, their units and types) are CP — they live in a schema registry and must be consistent, because a normalization built against the wrong schema produces garbage. Live price and stock are AP with bounded staleness — a price 30 seconds old is fine, and you would rather show a slightly stale price than fail the whole matrix. And compare lists are CP per user with optimistic concurrency — a user's compare tray is their own, edited with a version check so concurrent tabs do not clobber each other. Naming those three models up front — CP schema, AP prices, CP-per-user lists — is the framing that shows you understand the system is a read-heavy aggregation over data with very different freshness needs.