Problem statement
Design the object model and core APIs for a reminder service that fires time-based reminders at the right moment, supports snoozing and recurrence, and never fires the same occurrence twice.
Operating context. A user creates reminders, each with a due time, an optional recurrence (none, daily, weekly, or a custom interval), and a priority. A scheduler tracks the next reminder due across all of them and, when its time arrives, dispatches it to a notification sink and — if recurring — schedules the following occurrence. The user can snooze a fired reminder for a chosen delay, mark it done, edit its time, or delete it. Many reminders exist but only the soonest matters at any instant, so due lookup must be cheap. Single process; time comes from an injected clock so tests can jump forward.
Out of scope. The notification transport (push / sound / email), cross-device sync, natural-language date parsing, calendar / event modelling with attendees, and the UI — model the scheduling core and reminder lifecycle.
What to produce. The class hierarchy (Reminder, the recurrence rule, the due-time scheduler / queue, a dispatcher, a notification sink interface), the public API each exposes, and the states a reminder moves through. Be explicit about: the data structure that yields the soonest-due reminder in better than linear time, how snooze and recurrence reschedule without duplicate firings, and how a new recurrence rule is added without editing the scheduler.
Functional requirements
- Create a reminder with a due time, an optional recurrence rule, and a priority.
- Return the single soonest-due reminder and fire it when its time arrives.
- On firing a recurring reminder, schedule its next occurrence from its recurrence rule.
- Snooze a fired reminder for a given delay so it fires again later.
- Mark a reminder done, edit its due time, or delete it, updating the schedule accordingly.
Non-functional requirements
- Fetching and removing the soonest-due reminder is O(log N) or better via a priority structure, not a scan.
- Recurrence rules are pluggable behind one interface so a new cadence is added without editing the scheduler.
- Each occurrence fires exactly once — snooze, edit, and reschedule never cause a duplicate or a lost firing.
- All timing runs against an injected clock so tests fast-forward without real waiting.
- The scheduler is thread-safe if a dispatch thread and a user edit touch the queue at once.
- The scheduling core is unit-testable with a fake clock and a fake notification sink.
Topics
- System Design LLD
- Oop Solid
- Domain Scheduling
- Patterns State
- Concurrency Timers