ORIGINAL SYSTEM DESIGN QUESTION
Reliable practice notifications
Design a service that reminds learners about scheduled practice. Support email and push, local time zones, opt-outs and delivery history.
Original exercise · foundation. Editorial role relevance does not imply a company has asked this question.
Requirements and constraints
- 100,000 daily active learners; assume two scheduled reminders per learner per day.
- A provider may be unavailable for 30 minutes. Sending duplicate reminders is undesirable.
- Personal data and delivery tokens must be protected.
Pressure round
One notification provider is down while a backlog is building. Explain how you prevent a retry storm and prioritize overdue work.
Build and explain the design
Requirements & scope
Who uses it? What must it do? What is explicitly out of scope? State latency, durability and privacy goals.
Self-review guidance
Separate scheduling, channel preferences, quiet hours and delivery expectations. Distinguish desired delivery from guaranteed delivery.
Capacity estimates
State assumptions, peak requests/second, data volume and retention. Show your arithmetic and units.
Self-review guidance
200,000/day is about 2.3/second on average; explicitly choose a peak multiplier. Estimate queue retention and record size.
APIs & data model
Describe endpoints/events, entity keys, indexes, authorization, and idempotency.
Self-review guidance
Consider a schedule resource, delivery attempt resource, unique reminder ID and an authorization boundary for opt-outs.
Architecture & data flow
Describe components and request/event paths. Use plain text arrows to sketch your design; explain each responsibility.
Self-review guidance
A scheduler can enqueue delivery tasks; channel workers call providers. Describe the durable state transition and deduplication boundary.
Failures & observability
What happens on overload, duplicate events, partial failures or lost dependencies? Discuss monitoring and recovery.
Self-review guidance
Discuss bounded retries with backoff, dead-letter handling, provider timeouts, lag metrics and the unavoidable ambiguity after a provider accepts a request.
Tradeoffs & alternatives
Compare two plausible approaches. State the costs, consistency model and what would make you change the design.
Self-review guidance
Compare polling with delayed queues; distinguish at-least-once work from exactly-once external delivery claims.
Design guidance describes assumptions and tradeoffs; no architecture has been simulated or benchmarked.
Practice this question
Save your work privately, explain decisions and return to your revision queue.
Open practice workspaceBrowse the question library →