Design Price Comparison Engine

Problem Statement: Cross-Retailer Price Comparison

A price comparison engine is fundamentally a data-aggregation and identity-resolution problem wearing a shopping UI: it ingests offers from hundreds of merchants, resolves them to a single canonical product, and surfaces the lowest landed cost — the real price after shipping and tax, not the sticker. Think Google Shopping, PriceGrabber, or Idealo on the buy side, and camelcamelcamel on the price-history-and-alert side.

The defining insight, and the thing interviewers listen for first, is how you model a price. A naive design stores 'the price of product X' as a column you overwrite. That is wrong here, because there is no single price — there are many observed offers, each from a different merchant at a different moment, and each is an eventually consistent fact with provenance: who reported it, when, and how (a partner feed, a webhook, or a crawl). The right model is an append-only stream of observations from which the current best offer is derived, never a mutable catalog row. This is the same ledger-versus-balance discipline that shows up in payments and loyalty, applied to prices.

The scale is read-heavy and ingestion-heavy at once. Plan for roughly 40M monthly comparison shoppers, about 250M tracked SKUs each carrying 3–8 live offers, and on the order of 1.2B price observations ingested per day from feeds and crawls combined. The compare API peaks near 18k QPS, and on deal days like Black Friday the price-drop alert fan-out bursts to around 400k notifications per hour.

The failure that defines the design: a merchant runs a two-hour flash sale, our crawler captures the \$49 price, and the sale ends — but our cached offer still shows \$49 for another hour. A shopper clicks through, lands on a \$79 page, and loses trust permanently. Freshness, provenance, and honest staleness signaling are therefore not features but the core product, and everything downstream serves them.