Add Hold-Available and Loan Due-Date Notifications to a Library Lending System

You are working in an existing full-stack **Library Lending System** repository: a backend API, a frontend, and a test suite that already passes. A product manager (played by an AI chat assistant) describes a new feature conversationally, so the full specification is not given up front, and no existing or hidden tests cover the new behavior. Add notifications to the system. The requirements that come out of the conversation fall into two areas. **Hold notifications** - Notify a patron when an item they placed a hold on becomes available. - Respect hold queue priority. - Check whether the patron is eligible, taking overdue items and account status into account. - Avoid duplicate notifications. **Loan reminders** - Notify a patron when a loan is approaching its due date. - Notify a patron when a loan becomes overdue. - Avoid sending duplicate reminders. The change spans persistence, backend business logic, API endpoints, and a frontend notification UI. ### Constraints and Clarifications - Assume the application already records loans with due dates and holds placed on items in a queue. If the queue order is not stored explicitly, capturing it is part of the work. - The existing test suite must keep passing. Earlier changes in the same codebase, such as how item availability is computed or displayed, may be affected by this feature, and bugs it exposes in them are in scope. - Policies the product manager has not settled should be raised as questions, not silently decided. ### Clarifying Questions - How far before the due date counts as "approaching," and is there one reminder or several? - Which conditions make a patron ineligible: any overdue loan, a limit on overdue items, a blocked or suspended account? What happens to an ineligible patron's hold: skipped for now, kept in place, or cancelled? - Once a patron is notified, is the item reserved for them, and for how long? What happens if they do not collect it? - Is an overdue notice sent once, or repeated until the item is returned? - Are in-app notifications sufficient, or are email or other channels required now? - Are due dates timestamps or calendar dates, and in which time zone is "overdue" decided? ### Part 1 — Rules and Persistence Turn the conversation into explicit rules and design the persistence changes: what is stored for a notification, what additional state holds and loans need, and how duplicates are prevented. ```hint Name each notification event Decide what uniquely identifies one logical notification, so that a retry or a second worker can recognize that it already exists. ``` #### What This Part Should Cover - The notification record: recipient, type, related loan or hold, content, read state, and timestamps. - How duplicates are prevented, and whether that guarantee holds under retries and concurrent writers. - The hold state needed for queue order and for knowing which patron has been notified. - Each unresolved policy stated as an assumption, tied to the question it depends on. ### Part 2 — Hold-Available Notifications Implement the logic that runs when an item becomes available: choose which patron to notify, apply the eligibility rules, and notify exactly once. ```hint Enumerate what frees an item A return is the obvious trigger. Consider which other state changes can leave an item free for the next patron in the queue. ``` #### What This Part Should Cover - The triggers, and where the logic runs relative to the transaction that frees the item. - Queue ordering, the eligibility check, and what happens when the first patron in line is ineligible. - Behavior under concurrent or repeated events affecting the same item. - Consistency with how the rest of the application decides that an item is available. ### Part 3 — Due-Soon and Overdue Reminders Implement reminders for loans approaching their due date and for overdue loans. ```hint Nothing requests a reminder No user action happens when a loan crosses a time boundary. Consider what runs the check, and what happens if it runs twice or misses a run. ``` #### What This Part Should Cover - The trigger mechanism and how due-soon and overdue loans are selected. - Safety across reruns, restarts, and overlapping runs, and recovery after missed runs. - Precise boundaries so a loan is never due-soon and overdue at once, including time-zone handling. - Behavior when a loan is returned, or its due date changes, after a reminder. ### Part 4 — API, Notification UI, and Tests Expose notifications to the frontend, build the notification UI, and write tests for the new behavior. ```hint Control the clock Time-dependent rules are hard to test when code reads the system time directly. Consider how a test could decide what "now" is. ``` #### What This Part Should Cover - Endpoints scoped to the signed-in patron for listing notifications and marking them read. - A UI with an unread indicator, a list, and mark-as-read, plus how it stays current. - Tests for queue priority, ineligible patrons, duplicate prevention on reruns, and due-date boundaries. - Regression checks on earlier behavior that depends on item availability. ### What a Strong Answer Covers - Conversational requirements converted into explicit, testable rules, with open policies raised rather than invented. - Duplicate prevention that survives retries, restarts, and concurrent workers. - Hold logic that follows queue order and eligibility and stays consistent with the application's availability rules. - Reliable time-based reminders with unambiguous boundaries. - A coherent change across persistence, business logic, API, and UI, verified by tests at each layer. ### Follow-up Questions 1. The reminder job crashes after creating half of the reminders. What happens on the next run, and how would you detect the crash? 2. How would you add email delivery without sending a duplicate email when the email provider times out after accepting a message? 3. A skipped patron clears their overdue items. Should they regain their place in the queue, and how does your data model support either answer? 4. Could due-soon and overdue notices be computed when the patron opens the page instead of being stored? What would you lose?