Section 6: Following One Price Drop Home - High-Level Architecture

Executive Summary: This section draws the whole system on one board: a thin extension and a small API in front, and behind them a pipeline of per-shard schedulers, a fetch broker that spends the 500 calls/s budget, a change detector, sharded evaluators and an outbox-fed Web Push sender. We walk Maya's Prime Day drop through it with timings, then defend what's missing on purpose: no cache, no per-watch jobs, no scraper.

The interviewer slides the marker across the table. "You've got the API and the data model. Show me the boxes, and then show me how one price drop actually reaches someone." The second half matters more. Walking one real event through the boxes is how you find the arrow that doesn't connect.

Two Planes, One Pipeline

Name the split out loud. Two planes barely touch:

• The request plane is user-facing and small: product lookups at ~3,500/s on Prime Day, watch edits at ~230/s, observation batches at ~3,500/s. It needs the 99.9% availability and p99 latency targets from Section 2.
• The pipeline plane never waits on a user. Its limits are the outbound fetch budget and the notification burst. It needs freshness and correctness: never notify on an unverified price, and never lose an intent.

They share only the sharded store, so a spike on one plane can't starve the other.