How the interviewer opens it
“Design a notification service that other teams in the company call when they want to notify a user: things like payment receipts, login codes, and marketing campaigns, over push, SMS, email and in-app.”
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
- notification types
- latency
- loss vs duplicates
- scale
- preferences
- providers
The answers stay with the interviewer. In a SysRound round, Alex answers them as an interviewer would.
Scope of a strong answer
Core requirements
- Accept a notify request and return immediately
- Deliver on push, SMS, email, in-app
- Respect user preferences/opt-outs
Usually out of scope
- Building our own SMS/email infrastructure
- Content authoring UI
What interviewers probe
- Exactly-once illusion
- Workers can crash after sending but before acking: the queue redelivers.
- Isolation and backpressure
- One slow provider or one big campaign can starve everything else.
- Dual write
- Writing to the DB and the queue separately can lose messages on crash.
Common mistakes
- Sending synchronously in the request path
- No per-channel isolation
- Ignoring preferences/opt-out
- Assuming the queue gives exactly-once
The bar by level
- Mid-level (L4/E4)
- Async queue + workers, retries and DLQ, preferences check.
- Senior (L5/E5)
- Per-channel/priority isolation, idempotency with a clear crash analysis, outbox, circuit breakers, expiry.
- Staff (L6+/E6+)
- Platform thinking: multi-tenant fairness across calling teams, provider abstraction and failover, observability/SLOs per channel, cost controls.