Design a Price Tracker

You want a pair of headphones, but not at $79.99. You paste the product link into a price tracker, set "tell me under $65", and forget about it. Three weeks later your phone buzzes: $64.99. You open the tracker and see a chart of every price that product has had for two years.

Interviewers like this question because the hard part is not storage or traffic. It is a budget: the shopping site has 500 million product pages and you may only fetch a few hundred a second, so you must decide what to look at, borrow observations from users, and still never send a false alert. The question means the kind of product Keepa offers, tracking one large store. The steps follow A Framework for Any Design. Try each "Your turn" box before you read on.

#Clarify the problem

• Functional: track a product by link; set an alert at a target price or a percentage drop; show a price-history chart; notify once when the price falls to the target; accept price reports from the extension.
• Non-functional: stay under 500 fetches a second to the site; check popular products every 2 hours and every tracked product at least daily; no alert on an unverified price; at most one alert per drop; chart loads under 200 ms.
• Out of scope: other stores, price predictions, product search, user accounts.

#Estimate the scale

The givens are the scenario's, not any real tracker's. A day is 86,400 seconds.

• Fetch budget: 500 × 86,400 = 43.2 million fetches a day.
• Observations: 43.2 million from fetching plus about 30 million extension reports ≈ 73 million a day.
• Price changes: assume 1 observation in 10 shows a new price: about 7.3 million changes a day, about 85 a second. The alert pipeline is small.
• Alerts: 50 million × about 100 B = 5 GB. One database holds them.

#Define the API

POST /alerts
  body: { "product_url": "https://shop.example/p/B0077", "target_cents": 6500 }
     or { "product_url": "...", "drop_percent": 15 }
  201 { "alert_id": "a-31", "product_id": "P-77",
        "current_cents": 7999, "last_checked": "2026-11-14T08:10Z" }
  404 not a product page we recognise
 
DELETE /alerts/{id}
 
GET /products/{id}/history?range=1y
  200 { "resolution": "day", "low_cents": 5999, "last_checked": "...",
        "segments": [ { "from": "2026-01-03", "to": "2026-02-11", "cents": 7999 }, ... ] }
 
POST /observations                  from the extension, signed install token
  body: { "product_id": "P-77", "cents": 6499, "currency": "USD",
          "seller": "store", "condition": "new", "seen_at": "..." }
  202 Accepted                      always, whatever is decided later
  429 too many reports from this install

The decision worth arguing is the 202. The extension never learns whether its report was believed. Validation happens asynchronously, against other reports and fetches, and a silent answer gives a cheater nothing to tune against.

A percentage alert is turned into an absolute target when it is created: 15% below $79.99 is $67.99. The matcher then only ever compares prices, and the user sees the exact number they will be alerted at.

#Model the data

price_segments                       -- one row per run of the same price
  product_id     VARCHAR(16)
  first_seen     TIMESTAMP
  last_seen      TIMESTAMP           -- moved forward by each matching observation
  cents          INT
  source         VARCHAR(8)          -- crawl | crowd (verified)
  PRIMARY KEY (product_id, first_seen)
 
alerts
  alert_id       VARCHAR(16) PRIMARY KEY
  user_id        BIGINT
  product_id     VARCHAR(16)
  target_cents   INT
  state          VARCHAR(8)          -- armed | fired
  fired_change   VARCHAR(16) NULL
  INDEX (product_id, state, target_cents)
 
crawl_state
  product_id     VARCHAR(16) PRIMARY KEY
  next_due       TIMESTAMP
  priority       REAL
  last_verified_cents INT

History is written in time order and read as "one product, one time range". That is the shape of a wide-column or time-series store keyed by (product_id, first_seen): one product's segments sit together, sorted, and a chart is one range scan. Alerts need a different query, "armed alerts on P-77 with a target at or above $64.99", which is an index range scan in a relational database. Crawl state is a priority queue; it lives with the crawler.

#High-level design

Two arrows are left out to keep the picture readable: the API servers write new alerts to the alerts database, and the crawler reads alert counts from it to set priorities. Both arrows into the price service pass through a log partitioned by product_id, so one instance handles each product's observations in order. Two copies of the same drop can then never both see $79.99 as the last price and emit two events. Step through a drop found by the crawler, two crowd reports, and the failures.

#Deep dives

Interviewers push on four things: spending the fetch budget, trusting crowd reports, storing and charting history, and alerting once.

#Spending the fetch budget

The crawler is the one from Design a Web Crawler, aimed at one site: a frontier, politeness, parsers. What is different is that the frontier is not "everything, eventually" but a priority queue ordered by next_due, and the interval for each product comes from how much users care. A token bucket in front of the fetchers holds the whole fleet to 500 a second, whatever the queue says.

One plan that fits the 43.2 million fetches a day:

Tiers simplify a score: more trackers, an alert target near the current price, a volatile price and a long time since the last look all raise priority. An alert 40% below the price does not need a fetch every 2 hours; one 2% away does.

Every verified extension report is a fetch you need not make: the product's next_due moves forward. The extension sees exactly the pages people care about, so it relieves the hot tier most.

#Trusting crowd reports

Extension reports are free, but each comes from a stranger's browser. Some are wrong by accident (a member price, a coupon, a used offer, a misread page); some on purpose. The rule: a crowd report can extend a price or ask for a check; it cannot, on its own, make a big change.

Concretely: the extension reads the same fields the crawler parses (seller, condition, currency), so they mean the same thing, and anything other than the public new price is dropped. A report that matches the last verified price just moves last_seen. A change of up to 10% from an install with a good trust score is accepted. Anything bigger, or from a new install, is held until a second install on a different network reports the same price within an hour, or a priority fetch confirms it. Trust rises when an install's reports later agree with fetches and falls when they do not. Each install is rate limited, so one install cannot flood the queue.

#Storing and charting history

Prices are flat most of the time, so storing every observation mostly stores repeats. Store segments instead: a new row only when the price changes, and a matching observation just moves last_seen forward. That is the 10x saving in the estimate, and it keeps the chart honest about gaps: if last_seen is 10 days before the next segment starts, the chart shows a gap, not a flat line nobody checked.

A one-year chart for a product that changes daily has 365 segments: one range scan, fast. For "all time" on a product that changes hourly, precompute daily rollups (low, high, last) and read those instead, so no chart reads more than about a thousand rows. Keep the all-time low in a per-product summary row, since every product page shows it.

#Alerting once per drop

Duplicates come from three places, and each has its own fix.

• Two sources see the same drop. The crawler and an extension both see $64.99. Only a change from the last verified price emits an event, so the second observation emits nothing.
• The pipeline redelivers. The event log delivers at least once, so the matcher can process c-501 twice. Every notification carries the key alert_id + change_id, and the notification system drops a key it has already sent. The alert's fired_change column also lets the matcher skip work it already did.
• The price flaps. $64.99, $65.01, $64.99 in one day is two drops below $65 by the letter of the rule, and one annoying user. A fired alert re-arms only when the price climbs 5% above the target, or when the user asks. The matcher checks this on each change event, with the same index.

A very popular product can match 200,000 alerts in one change. The matcher reads them in pages from the (product_id, state, target_cents) index and hands them over in batches; if the notification system sends 2,000 a second for this, the last user hears about 200,000 ÷ 2,000 = 100 seconds after the first, well within the 2-hour promise.

#Bottlenecks and failures

At 10x users the fetch budget does not grow; the site sets it. Intervals stretch, and the extension, which grows with users, matters more. History grows by less than 10x, because more observations catch more of the real changes but prices do not change more often. Even the worst case, about 850 GB a year, shards easily by product_id.

#What a strong answer sounds like

#Follow-up questions

#How do you start tracking a product nobody has tracked?

Fetch it at once, at top priority, so the user sees a current price and a history from the untracked tier if one exists. From then on it is in the tracked tier.

#How would you support many stores?

Each store gets its own budget and token bucket, its own parser, and its own frontier; the price service, history and alerts do not care where a price came from. Products sold by several stores need a matching step, which is a separate problem.

#How do you detect fake drops, where the price is raised before a "sale"?

The history already shows it. Compare the "sale" price with the median of the last 90 days, not with the price the day before, and label the drop honestly in the alert.

#Why not just fetch tracked products more often from many IP addresses?

Because the budget is the site's limit, not a technical one. Evading it is a fast way to be blocked entirely and to break the site's terms. Getting more coverage is what the extension and better priorities are for.

#How do you know the system is healthy?

Track the age of the last verified price per tier, the parse failure rate, the share of crowd reports that fetches contradict, and the time from a change event to a sent alert. A rise in contradictions is often a layout change, not cheaters.