Design Do Not Disturb

Easy45 min
1 / 30
understanding•9 min read

Problem Framing and Scope

How Problem Framing and Scope (understanding) informs Do Not Disturb architecture and interviewer depth.

Problem Framing and Scope

Apple Focus modes, Android Do Not Disturb, and Slack notification pauses all solve the same backend problem: translate human intent into a machine-checkable policy that every downstream notifier must honor before spending money on push tokens, SMS segments, or websocket fan-out.

In interviews, open with scope boundaries. You own schedule windows, per-surface muting, allow-lists for VIP senders, digest deferral, and audit-friendly reason codes. You do not own message storage, full push infrastructure, or marketing campaign builders unless the interviewer expands scope.

State three invariants early: (1) no delivery without an eligibility evaluation tied to a policy snapshot version; (2) legal or safety alerts may bypass user mute but must emit bypass_legal reason codes; (3) multi-device updates converge via monotonic versioning, not last-writer-wins on silent fields.

pythonOne Dark Pro
1from enum import Enum
2from dataclasses import dataclass
3from datetime import datetime
4 
5class DndDecision(str, Enum):
6    ALLOW = "allow"
7    SUPPRESS = "suppress"
8    DEFER_DIGEST = "defer_digest"
9    BYPASS_LEGAL = "bypass_legal"
10 
11@dataclass(frozen=True)
12class EvaluateRequest:
13    user_id: str
14    workspace_id: str
15    channel_id: str
16    category: str
17    policy_version: int
18    event_time: datetime

Section 1 interview angle

When discussing problem framing and scope, tie claims to measurable SLOs, explicit reason codes, and Slack/Apple/Android analogues—not generic notification advice.

Why interviewers care

Do Not Disturb 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 3am push that wakes the user during their quiet hours — because the DND check was skipped on a code path, or the quiet-hours window was evaluated in the wrong timezone. That single leaked interruption destroys the trust the whole feature exists to earn. The fix is the spine of the design: DND is a gate evaluated on the delivery path for every notification, timezone- and DST-correct, that suppresses the interruption (the push and sound) rather than dropping the message — the notification still appears in-app, only the wake-up is withheld. State DND-as-a-per-notification-suppression-gate up front, because do-not-disturb is judged entirely on never interrupting when it promised silence, and the cardinal failure is one push that should never have fired.

Key Highlights

  • •Problem Framing and Scope connects DND policy mechanics to interview-ready trade-offs.
  • •Separate product toggles from canonical policy graph
  • •Declare legal bypass semantics up front
Interviewer signal
State the invariant first: no notification is sent unless policy evaluation returns eligible with an explicit reason trace.
Design tip
Separate preference write-path from notification read-path so user updates stay fast while send checks remain horizontally scalable.

Section Rescue Kit

Buzzwords to use:

Policy Evaluation GraphIdempotent Fan-out

Safe statements:

  • "Let me anchor Problem Framing and Scope on explicit invariants before choosing infrastructure so trade-offs are transparent."
  • "If we need to simplify, I will keep the same event contract and reduce optional behaviors instead of changing correctness rules."
Design Do Not Disturb - System Design | WinJob | WinJob