Design Idempotent In-App Availability and Due-Date Notifications

Add a notification service to an existing web application. It must provide in-app notifications when an item becomes available and reminders related to an item's due date. Use Celery and Redis for asynchronous processing, and address idempotency and edge cases. Begin by eliciting the detailed requirements, then propose a design that can be implemented and tested. No specific database, reminder offset, delivery deadline, or item schema is prescribed. ### Constraints & Assumptions - The required delivery channel is the application's in-app notification feed. - Availability notifications and due-date reminders are distinct notification types. - Practice clarification: assume users can subscribe to an item, an availability transition can be identified, and a due date can change or be removed. Explain any additional data fields you introduce. - Workers can retry or restart. Do not assume that a task is executed only once. ### Clarifying Questions to Ask - Does every unavailable-to-available transition generate a new notification, or only the first transition for a subscription? - What is the reminder offset, which time zone defines a due date, and what happens if a due date is changed after a reminder was scheduled? - Should unsubscribing cancel pending notifications? Should already delivered notifications remain visible? - Is a missed reminder still useful after its scheduled time or after the due date? ### What a Strong Answer Covers - A data model connecting subscriptions, event identity, due-date versions, scheduled work, and visible notifications. - A reliable handoff from the application transaction to Celery tasks. - Idempotency enforced at the durable notification write, including concurrent duplicate workers. - Revalidation of availability and due-date work when subscriptions or item state change. - Tests for duplicate delivery attempts, stale schedules, worker crashes, and changes near the reminder time. ```hint Separate work delivery from notification creation A task can arrive more than once without requiring more than one visible notification. Decide where the durable uniqueness decision belongs. ``` ### Follow-up Questions - What happens if a worker commits the notification and crashes before acknowledging the task? - How would a changed due date invalidate old reminder tasks without relying on deleting every queued message? - How would you recover notification work if a database transaction committed but publishing to Redis failed?