我们大多数人都熟悉FB页面右上方弹出的通知。然后确认它们，我们仍然可以通过最新的第一次订购等方式看到它们。
我对设计这样的东西有疑问（为此也在拱的侧面尝试阅读）。因此，从高层次来讲，我们可以说系统中正在运行微服务
所以让我们说我有这样的服务。我正在考虑创建一个新的服务S4，该服务可以接收来自这些服务的消息。我不太担心这些服务将如何与S4通信。可以使用SQS，kafka等方法。
我的主要问题是S4如何执行以下操作
答案 0 :(得分：0)
以下是一些想法，但我认为没有一种方法可以适用于所有情况。这实际上取决于您的体系结构的其余部分，域要求，可伸缩性要求等。
以什么样的方式维护这些通知？ PSQL？
您是否真的需要将通知存储到事件队列之外？这可能取决于您的队列设计是否允许基于主题和消息内容的即时访问。许多队列系统允许您无限期地/直到处理完为止存储消息（请查看Apache Pulsar）。在这种情况下，存在积压的未确认消息，可以随时准备访问和处理（例如，客户端确认已读取消息）。确认后，您可以存档或删除事件。
如果您认为这行不通，并且需要一个额外的数据库，那么通常会产生疑问：键值存储（例如MongoDB）或关系数据库（例如CockroachDB）。
是否有带时间戳的列？
默认情况下，大多数队列系统都会记录一个时间戳。有时队列顺序可能就足够了。根据您的查询要求，在大多数情况下，至少需要消息内容的无模式格式（例如json或blob）和一些用于（用户等）查找消息的显式标识符。
我需要一个时间序列数据库吗？
如果您需要跟踪随时间变化的大量值，例如与物联网相关的传感器数据，例如温度测量。如果您每位用户只有少量的Facebook风格的通知，那似乎不合适。
如何根据严重性存储它们？致命，信息，关键吗？
在这里您可以利用事件队列中按主题进行的分隔，或者在使用单独的数据库时，这又取决于您使用模式还是无模式数据库。
某人如何确认通知？
如前所述，现代事件队列系统是内置的，或者，如果使用单独的数据库，则必须将其添加到架构中（或使用无架构的数据库）。无论哪种情况，您都需要定义或实现确认后的消息保留行为，例如是删除还是存档。