Notification systems look simple until you're dealing with user preferences, rate limiting to avoid spamming, digest batching, and multi-channel delivery. Claude Code builds these correctly when you give it the full picture upfront.
Define the notification types first
I'm building a notification system. Notification types:
- [type1]: triggered by [event], sent via [channels], frequency [?]
- [type2]: triggered by [event], sent via [channels], frequency [?]
User preferences: users can [mute specific types / set frequency / choose channels]
Rate limits: max [N] notifications per [period] per user
Digest: [daily/weekly digest for lower-priority types]
Design the data model before implementing anything.Getting the data model right before implementation prevents major refactors. Notification systems have non-obvious schema requirements: tracking delivery status per channel, storing user preferences per type, handling digest batching.
The notification service
Build a notification service. It should:
1. Accept: notification type, recipient, data
2. Check user preferences: is this type enabled for this user?
3. Check rate limits: has this user hit their limit?
4. Route to appropriate channel(s) based on type and preferences
5. Queue delivery (async — don't send in the request path)
6. Track delivery: sent, delivered, failed
Single interface for all notification types — no per-channel logic in callers.Email notifications
Implement email notifications using [Resend/SendGrid/SES].
Requirements:
- Template per notification type (not string concatenation)
- Track: sent, opened (if tracking enabled), clicked
- Unsubscribe link in every email
- Handle bounces: mark email as invalid, stop sending
- Handle complaints (spam reports): unsubscribe immediately
- Retry on transient failures, give up on permanent failuresNotification preferences UI data
Build the backend for a notification preferences page.
User should be able to:
- Enable/disable each notification type
- Set channel preference per type (email/push/in-app)
- Set digest frequency for digests (immediate/daily/weekly/never)
- Unsubscribe from all with one action
Return current preferences and update preferences endpoints.Digest batching
Implement digest batching for [notification type]:
- Collect events during [period]
- At [scheduled time], send one digest per user who has pending events
- Digest includes: count, summary, link to full list
- If user has 0 events: don't send
- Mark all included events as digest-sent
Idempotent: safe to run the digest job twice (don't double-send).Testing notifications
Write tests for the notification service. Test:
- Normal delivery: notification queued for appropriate channels
- User preference off: notification not queued
- Rate limit hit: notification not queued, logged
- Digest batching: multiple events produce one digest
- Unsubscribe: no further delivery after unsubscribe
Use a fake/in-memory delivery backend for tests — don't send real emails.Notification system patterns are in the Agent Prompt Playbook. $29.