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?