Design Price-Drop Alerts

Watches are stored so that every watcher of one product, filtered by target price, can be read without a scan: partitioned by product id with the target price in the sort key (or an equivalent index), plus a per-shopper view for listing.

Price changes are consumed from the pricing system's event stream rather than polled, and only real drops (new price below the previous one) start any work.

A drop on a product with millions of watchers is split into bounded batches processed in parallel by many workers, so no single worker, partition or queue shard carries a popular product alone.

An alert record keyed by shopper, product and day is written atomically before (or as) the alert is sent, and consumers are idempotent, so queue redelivery or worker retries can never send twice.

Monthly totals are converted to rates (about 7,000 price changes a second on average, 35,000 at peak, of which roughly 140 and 700 are drops) and the watch store is sized (300 million rows of about 100 bytes is tens of gigabytes).

Every functional requirement in the brief is visibly served by something on the board, and the non-functional targets are addressed rather than ignored.

Components are labelled, data flows are drawn as connections between them, and the direction of each flow is unambiguous.