How the interviewer opens it
“Design a price alert system where users ask to be notified when a product or stock drops below a chosen price. We need to support millions of alerts and notify users quickly when their conditions are met.”
The prompt is vague on purpose. The first few minutes are yours: narrow it to the core features and agree on the numbers before you draw anything.
What to clarify first
- Price source and instrument identity
- Alert semantics
- Stored scale and skew
- Traffic and read:write mix
- Latency
- Ordering and brief price changes
- Consistency, availability, and durability
- Notification channel and provider
- Retention
- Deployment and scope
The answers stay with the interviewer. In a SysRound round, Alex answers them as an interviewer would.
Scope of a strong answer
Core requirements
- Create, list, and cancel price alerts
- Receive price updates from a trusted external feed
- Trigger an alert when its instrument's price meets its threshold
- Submit notifications reliably without blocking price processing
Usually out of scope
- Scraping merchants or building exchange-feed connectors
- Trade execution and order management
- Currency conversion and combining conflicting price sources
- Historical price charts and analytics
What interviewers probe
- Finding matching thresholds without scanning every alert
- Most prices match nothing, but a popular instrument can have a million alerts and thousands of updates per second. Indexing only by instrument still leaves an expensive scan on the hottest key.
- Ordering price updates, registration, and cancellation
- A correct threshold index can still miss alerts if activation races with a price drop. Keeping only the latest price also erases short-lived qualifying prices.
- Durable triggering versus external delivery
- Changing an alert to triggered and contacting a push provider cannot be one database transaction. Crashes can lose a notification or duplicate it, and a provider timeout does not reveal whether it accepted the request.
- A million alerts firing on one price update
- Input partitioning distributes ordinary price traffic, but one price can create a huge output burst. The external provider quota leaves little room inside the 60-second target.
Common mistakes
- Treating millions of alerts as a reason to scan them periodically without checking hot-instrument costs or brief-dip semantics.
- Indexing by user for the evaluation path, even though incoming events are keyed by instrument.
- Using a latest-price cache as the entire event history and silently missing transient qualifying prices.
- Ignoring activation and cancellation races, or comparing prices with floating-point values and unspecified currencies.
- Separating the triggered-state update from durable notification creation, then claiming the queue guarantees exactly-once delivery.
- Ignoring output fanout and provider quotas because the incoming price event itself is small.
The bar by level
- Senior (L5/E5)
- Defines one-shot and cancellation semantics, orders price and alert changes per instrument, preserves brief dips, and closes the state-to-notification crash gap. Quantifies hot-key and fanout costs, uses recoverable evaluation state, and handles provider ambiguity without claiming impossible delivery guarantees.
- Staff (L6+/E6+)
- Separates the input-ordering, matching, fanout, and delivery bottlenecks. Explains safe hot-instrument ownership changes and restartable large matches, derives the provider-limited burst SLO, and protects ordinary traffic during correlated bursts. Can adapt to recurring alerts, feed recovery, and regional failover while stating which guarantees must change.