Desenhe um sistema de notificações que envia e-mails e alimenta um feed dentro do app.

Grave a notificação em uma tabela como fonte da verdade, depois enfileire um job de entrega por canal para um provedor de e-mail com problema nunca bloquear o feed no app. Faça os jobs idempotentes e com retentativas em backoff exponencial até uma fila de mensagens mortas. Sirva o feed a partir daquela tabela, empurrando atualizações por socket ou fazendo poll no foco. Adicione preferências por usuário e agrupamento em resumo para ninguém receber vinte e-mails por hora.

Eu modelaria uma tabela de notificações indexada por usuário com um tipo, um payload, um timestamp de criação e um timestamp de leitura, e trataria aquela linha como a verdade. Criar uma notificação é uma escrita só mais o enfileiramento dos jobs de entrega, um por canal, então se o provedor de e-mail está fora o feed no app continua funcionando e o e-mail tenta de novo depois. Cada job carrega uma chave de idempotência estável formada pelo id da notificação e pelo canal, então uma retentativa não consegue enviar duas vezes. As retentativas usam backoff exponencial e caem em uma fila de mensagens mortas depois de algumas tentativas, com um alerta, porque falha silenciosa de e-mail é o tipo de bug que você descobre por um cliente. O feed em si é uma leitura paginada simples naquela tabela, com contagem de não lidos em cache, e eu empurro itens novos por server sent events ou simplesmente busco de novo quando a aba recupera o foco. No lado do produto, as preferências ficam por usuário e por tipo, os tipos de alto volume são agrupados em um resumo diário, e todo e-mail carrega um descadastro de um clique que de fato escreve de volta naquelas preferências.