Problem Framing and Scope
How Problem Framing and Scope (understanding) informs Notification Preferences architecture and interviewer depth.
Problem Framing and Scope
What we are designing
A notification preference platform for collaboration products (Slack, Discord, Apple-style ecosystems). The system stores user intent—mute, digest, channel overrides, category toggles, quiet hours—and evaluates that intent on every candidate notification before expensive fan-out to mobile push, email, or in-app surfaces.
In scope
- CRUD for preferences at user, workspace/org, channel, and category granularity
- Override resolution when rules conflict (e.g., channel mute vs @mention exception)
- Evaluation API called by the notification hub with sub-10ms p99 in-region
- Audit trail: immutable log of policy version + decision + reason code
- Multi-device sync with optimistic concurrency (ETags / version vectors)
Out of scope (state explicitly in interviews)
- Owning APNs/FCM delivery pools (assume existing push service)
- Message content ranking / ML feed (only optional extension section)
- Full marketing campaign builder
Core interview hook
Strong candidates say: "I am not designing toggles; I am designing a versioned policy graph evaluated on every event." That sentence separates Staff-level answers from CRUD endpoints.
Scale assumptions (stated)
| Signal | Value | Notes |
|---|---|---|
| DAU | 35M | Multi-workspace users |
| Preference writes | ~12K/s peak | Burst during onboarding |
| Eligibility checks | ~220K/s | Every candidate send |
Architecture boundary
1 Product Event → Preference Evaluator → {allow|deny|defer|digest} → Delivery Orchestrator
Mention Slack's channel notification settings and Apple's Focus modes as real-world analogues—then map to your canonical model.
Why interviewers care
Notification Preferences interviews reward crisp scope, explicit trade-offs, and failure stories—not generic microservice diagrams.
The failure that defines the design
The outage to narrate is the preference check that gets bypassed. Notification preferences only work if EVERY send path consults them — and the classic failure is a new feature or a batch job that sends directly, skipping the preference service, so users get notifications they explicitly turned off, or worse, messages during quiet hours or after unsubscribing (a compliance violation). The fix is structural: the preference evaluation is a mandatory gate on the send hot path that no producer can route around, with the default being do-not-send when in doubt. A preference service lives or dies on being unbypassable, because a single send that ignores it breaks user trust and the law.
Key Highlights
- •Preferences are policy state, not UI labels
- •Scope: Slack/Discord-class workspace granularity
- •Separate write path from eligibility read path
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "For Problem Framing and Scope, I would lead with concrete invariants and reason codes before naming any cloud service."
- "If time runs short on Problem Framing and Scope, I keep the policy pipeline intact and trim optional channels—not correctness rules."