Section 2: Promises a Test Can Break - Requirements (Functional & Non-Functional)

Executive Summary: This section converts Section 1's assumptions into a contract: five functional capabilities, and non-functional requirements a test can verify, including per-tier freshness, a 60-second notification p99, 99.9% availability, under 0.01% duplicates, no silent loss, and never notifying on an unverified price. We name what is out of scope and why, and surface the tension that shapes the whole interview: fresh prices against a fixed fetch budget.

The interviewer asks: "So what are we building, and how will we know it works?" They want requirements that can fail loudly. "Notifications should be fast" can't fail. "Price-change event to push-service 201 Created in under 60 seconds at p99, including the worst burst" can, which is why it's worth writing down.

The Functional Contract

Five capabilities, each traceable to something Maya actually does:

• Watch a product: Create, edit, pause and delete a watch on a product with a target price. There is exactly one watch per (user, marketplace, ASIN). If Maya changes their $299.00 target on B0EXAMPLE4 to $289.00, they have edited their watch, not created a second one.
• Look up a product: On each product page the extension asks for the current price, when we last checked it, the 90-day low, and whether this user is watching. It's the highest-volume user-facing call.
• Notify on a crossing, once: When the verified price drops to or below the target, the user gets one Web Push notification for that crossing, not one per later check. The watch goes from ARMED to TRIGGERED and re-arms only after the price climbs at least 2% above the target, with at most one notification per watch per 24 hours.
• Manage devices: Register, replace and drop push subscriptions. Maya has two (Chrome on the laptop, Firefox on the desktop), and a notification goes to both.
• Accept opportunistic observations: The extension can report the price it saw on the page. These are hints: they can request an early authoritative check but never trigger a notification.

Interviewer: "Why does the once-per-crossing rule belong in the requirements? Isn't that an implementation detail?"

You: "It's the product's behaviour, so it's a requirement. Without it, a price that sits at $278 for a week notifies Maya every 15 minutes, 672 times, and users uninstall over spam. The opposite mistake, one-shot-forever, means Maya misses the better deal next month. Re-arming with 2% hysteresis and a 24-hour cap sits between the two. If research later wants 'tell me about further drops', Section 12 adds a ladder."

Key Insight: A notification product fails in two directions: spam (duplicates, repeat alerts, glitch fan-outs) and silence (lost alerts). Users forgive neither, and every correctness NFR below guards one of them.

Quick check before moving on: