The Watchlist Interview: Designing an Amazon Price Watch & Notification Service

A shopper opens a product page, types a number, and walks away. Weeks later, on a Tuesday morning, their laptop chimes: the headphones you wanted just dropped below your price. It feels like magic. Behind it sits one of the most instructive problems in the Staff/Principal interview toolkit: millions of people quietly waiting on millions of products, a price source you are only allowed to ask so many questions per second, and a notification that has to arrive once, promptly, and only when it's true.

Why Interviewers Love This Question

The price-watch prompt looks like CRUD with a cron job. It isn't, and the interview is built to find out whether you notice. Three traps sit just under the surface:

• The Cron-Per-Watch Trap: The candidate schedules a check for every watch. Fifty million watches become fifty million jobs, and a popular product watched by 18,000 people gets fetched 18,000 times. Signal: the candidate designs around the user's object, not the system's scarce resource.
• The Trust-the-Client Trap: The extension can already see the price, so why not believe it? Because one script reporting "$1" would wake half a million people. Signal: trust boundaries drawn in the wrong place.
• The Exactly-Once Trap: The candidate promises exactly-once delivery across a push service and a browser they don't control. Signal: guarantees claimed, not engineered.

The passing performance turns each trap into a design decision: schedule by product against a fixed fetch budget, evaluate only the watches a price change actually crossed, and deliver at-least-once, made effectively-once with deterministic ids, a ledger, and the Web Push protocol's own collapse mechanism.