Design Idempotent Due-Date and Hold Notifications

# Design Idempotent Due-Date and Hold Notifications Extend a library-management system with two notification workflows: 1. A patron receives a notification 24 hours before a borrowed item is due and another when it becomes due. 2. Patrons may place holds on an item. When `N` copies become available, notify the first `N` eligible patrons in FIFO hold order. Design the backend and the related frontend states. The workflows must be idempotent, tolerate retries and worker crashes, and have meaningful unit and integration coverage. ### Constraints & Assumptions - Multiple patrons may hold the same item, but one patron has at most one active hold per item. - A due date or hold can change while notification work is queued. - Notification delivery providers can time out, retry, or return duplicate callbacks. - “Notify” does not by itself guarantee that a patron successfully claims a copy. - The prompt does not specify notification channels, reservation expiry, or time-zone policy; establish them before finalizing behavior. ### Clarifying Questions to Ask - Which channels are supported, and what are the delivery guarantees? - Which time zone defines “24 hours before” and “due”? - Does notification create a temporary reservation, and how long does it last? - What makes a patron ineligible, and how are canceled holds removed? - Can due dates renew, and should a changed due date create new notification identities? ### Solving Hints - Give every logical notification a stable identity derived from the business event it represents. - Claim hold recipients and available copies atomically before sending anything. - Recheck mutable business state when scheduled work executes. ### What a Strong Answer Covers - Data models for loans, holds, copies or inventory, notification intents, and delivery attempts. - Stable idempotency keys and uniqueness constraints for each logical notification. - Scheduling and transactional outbox behavior for due-date events. - FIFO hold selection with concurrency control and an explicit reservation/claim model. - Retries, ambiguous provider responses, reconciliation, cancellation, and expiry. - Frontend states that distinguish a hold, an offered copy, and a completed checkout. - Tests for time boundaries, duplicates, concurrent returns, changed due dates, and failed delivery. ### Follow-up Questions 1. Two copies are returned concurrently; how do you prevent both transactions from offering the same queue position? 2. What happens when a patron's notification is undeliverable? 3. How do renewals or due-date edits cancel stale scheduled notifications? 4. How would you recover if the scheduler was unavailable for several hours?