Ниже приведены некоторые мысли, но я не думаю, что есть один подход, подходящий для всех.Это действительно зависит от остальной части вашей архитектуры, требований к домену, требований к масштабируемости и т. Д.
Поддерживать эти уведомления, как что?PSQL?
Вам действительно нужно хранить уведомления дополнительно к очередям событий?Это может зависеть от того, позволяет ли ваш дизайн очереди обеспечивать своевременный доступ на основе тем и содержимого сообщений.Многие системы очередей позволяют хранить сообщение неограниченно / до его обработки (см. Apache Pulsar).В этом случае существует резервная копия неподтвержденных сообщений, которые могут быть доступны и обработаны, когда они будут готовы (например, клиент подтверждает, что сообщение было прочитано).После подтверждения вы можете заархивировать или удалить события.
Если вы решите, что это не работает, и вам нужна дополнительная база данных, в игру вступают обычные подозреваемые: хранилища ключей-значений, такие как MongoDB или RelationalDB, например CockroachDB.
Есть столбец с отметкой времени?
В большинстве систем очередей по умолчанию записывается отметка времени.Иногда порядка очереди может быть достаточно.В зависимости от требований к вашему запросу в большинстве случаев потребуется как минимум схема (например, json или blob) для содержимого сообщения и некоторые явные идентификаторы для поиска сообщений (пользователем и т. Д.).
Нужна ли для этого база данных временных рядов?
Возможно, это полезно, если вам необходимо отслеживать большое количество изменяющихся во времени значений, например, данные датчика, связанные с IOT, такие как измерение температуры.Если у вас есть несколько уведомлений в стиле Facebook на пользователя, которые не очень подходят.
Как я могу хранить их в зависимости от серьезности?Неустранимый, информация, критический?
Здесь вы можете использовать разделение по темам в очередях событий или при использовании отдельной БД, снова зависит, используете ли вы схему или БД без схемы.
Как кто-то может получить уведомление?
Как уже упоминалось ранее, современные системы очередей событий имеют это встроенное или, если вы используете отдельную БД, вам придется добавить это в схему (или использовать БД без схемы).В любом случае вам нужно определить или реализовать поведение для сохранения сообщений после подтверждения, например, удалять ли или архивировать.