Section 7: Spending Five Hundred Calls a Second - Deep Dive: Scheduling by Product

Executive Summary: We start the deep dives with the fetch budget, the only resource we cannot buy more of tomorrow. This section shows why we schedule by ASIN, not by watch, then walks the machinery: per-shard schedulers that lease due products with FOR UPDATE SKIP LOCKED, a fetch broker with priority lanes and a global token bucket, batching 10 ASINs per call, the Prime Day reconfiguration, and a hint lane that turns cheap extension observations into a few expensive verifications without ever letting them notify anyone.

"Where would you like to go deeper?"

Three walls carry this design: the fetch budget (do we ever see Maya's $278.00?), sharded evaluation (does it find the right 12,400 watchers?) and delivery (does exactly one notification land?). Section 3 showed the outbound budget, not inbound QPS, is the real limit, so we start there.

You: "The licensed API gives us 500 calls a second at 10 ASINs a call, so 5,000 checks a second, and it never grows because we added servers. Every design choice in this section is about spending those checks where a price change actually matters."

Why the Unit of Work Is the Product

The naive design schedules one job per watch: 50M cron jobs, each fetching its own product. But we only have 15M distinct watched ASINs, so that design fetches the average product about 3.3 times per interval, and the duplication is worst exactly where it hurts. Maya's headphones, B0EXAMPLE4, have 18,000 watchers. Per-watch scheduling fetches that price 18,000 times. Per-product scheduling fetches it once, and the evaluator in Section 8 fans the single result out to every watcher.

The flip trigger: if prices became personalized per region, the schedule key would become (asin, region). The rule holds: schedule by what you fetch, not by who asked.