Diseña un sistema de notificaciones que envíe correos y alimente un feed dentro de la aplicación.

Escribe la notificación en una tabla como fuente de verdad, y luego encola un trabajo de entrega por canal para que un proveedor de correo caído nunca bloquee el feed de la aplicación. Haz los trabajos idempotentes y reintenta con retroceso exponencial hacia una cola de mensajes muertos. Sirve el feed desde esa tabla, empujando actualizaciones por socket o sondeando al recuperar el foco. Añade preferencias por usuario y resúmenes para que nadie reciba veinte correos por hora.

Modelaría una tabla de notificaciones indexada por usuario con un tipo, una carga útil, una marca de tiempo de creación y otra de lectura, y trataría esa fila como la verdad. Crear una notificación es una única escritura más encolar trabajos de entrega, uno por canal, así que si el proveedor de correo está caído el feed de la aplicación sigue funcionando y el correo se reintenta después. Cada trabajo lleva una clave de idempotencia estable formada por el id de la notificación y el canal, así que un reintento no puede enviar dos veces. Los reintentos usan retroceso exponencial y acaban en una cola de mensajes muertos tras unos pocos intentos, con una alerta, porque un fallo silencioso de correo es de esos bugs de los que te enteras por un cliente. El feed en sí es una lectura paginada simple sobre esa tabla, con los contadores de no leídos cacheados, y empujo los elementos nuevos por server sent events o simplemente vuelvo a pedirlos cuando la pestaña recupera el foco. En el lado de producto, las preferencias viven por usuario y por tipo, los tipos de mucho volumen se agrupan en un resumen diario y cada correo lleva una baja en un clic que de verdad escribe en esas preferencias.