Design a notification system that sends emails and powers an in app feed.

Write the notification to a table as the source of truth, then enqueue a delivery job per channel so a failing email provider never blocks the in app feed. Make jobs idempotent and retry with exponential backoff into a dead letter queue. Serve the feed from that table, pushing updates over a socket or polling on focus. Add per user preferences and digesting so nobody gets twenty emails an hour.

I would model a notifications table keyed by user with a type, a payload, a created timestamp and a read timestamp, and treat that row as the truth. Creating a notification is a single write plus enqueueing delivery jobs, one per channel, so if the email provider is down the in app feed still works and the email retries later. Each job carries a stable idempotency key made from the notification id and channel, so a retry cannot double send. Retries use exponential backoff and land in a dead letter queue after a handful of attempts, with an alert, because silent email failure is the kind of bug you find out about from a customer. The feed itself is a simple paginated read on that table, with unread counts cached, and I push new items over server sent events or just refetch when the tab regains focus. On the product side, preferences live per user per type, high volume types get digested into a daily summary, and every email carries a one click unsubscribe that actually writes back to those preferences.