Problem statement
Design the object model and core APIs for a habit-tracking app that helps one user build routines by logging daily check-ins and keeping streaks accurate.
Operating context. A user defines habits, each with a target cadence — every day, specific weekdays, or a count of times per week. The user marks a habit done for a given date; the system records the check-in and recomputes the current and longest streak under that habit's cadence rules. Habits can be paused (streak frozen, not broken) and later resumed, or archived. The app shows per-habit statistics and flags a habit that is due today and still unchecked so a reminder can be raised. Everything runs on-device, in-process.
Out of scope. Cloud sync across devices, social sharing and leaderboards, the notification transport (push / email plumbing), ML habit suggestions, and the UI layer — model the domain, not the screens.
What to produce. The class hierarchy (Habit, CheckIn, cadence / schedule rules, the streak calculator, a due-today query, statistics), the public API each exposes, and the states a habit moves through. Be explicit about: how differing cadences share one streak-computation path, how a pause freezes rather than breaks a streak, and how a new cadence rule (e.g. 'weekdays only') is added without editing the streak engine.
Functional requirements
- Define a habit with a target cadence: daily, chosen weekdays, or a weekly frequency count.
- Record or undo a check-in for a habit on a specific date.
- Compute a habit's current streak and its longest-ever streak under its cadence rules.
- Pause a habit so its streak freezes, then resume it without counting the gap as a miss.
- List habits that are due today and still unchecked so a reminder can be raised.
- Report per-habit statistics such as completion rate over a chosen window.
Non-functional requirements
- Streak recomputation is bounded by the check-ins in the affected window, not the habit's entire history.
- Cadence rules are pluggable behind one interface so a new rule type is added without touching the streak calculator or Habit.
- All date logic runs against an injected clock / calendar so tests can simulate any day without waiting.
- The domain model is unit-testable with no persistence and no real timer.
- Reminder evaluation is thread-safe if a background scheduler and a user check-in run concurrently.
- Adding a new statistic does not modify Habit or the check-in store.
Topics
- System Design LLD
- Oop Solid
- Patterns Strategy
- Domain Scheduling
- Patterns Observer