背景
我正在为包含一些社交网络功能的客户端开发应用程序。我原本是在开发移动前端，但当时的情况也让我负责开发后端。
作为一般背景，我们的系统允许用户关注其他用户，并收到有关他们关注的人的通知，这是您期望从社交网络获得的。需要注意的是，只有一小部分用户（最多几百个）是可追踪的，并期望大多数用户群将关注这些个人中的至少一个。
在用户界面侧，我们将有一个带有数字的通知按钮，单击该按钮将带您进入通知屏幕。
问题
我一直在研究实现通知的策略，发现的大多数资源都指向在数据库中创建一个或多个通知表。（我喜欢的一个示例是此处接受的答案：https : //stackoverflow.com/questions/9735578/building-a-notification-system）。
让我烦恼的是，大多数数据库驱动的通知策略都要求为每个关注者的每个通知插入一行。因此，如果有一千人在关注Sally，我们将在相应表中插入一千行。那可扩展吗？如果我们到了成千上万的用户关注Sally并且她每天发表数十条帖子的情况，会发生什么？
我最初的想法是处理查询的所有问题：通知按钮上的数字将通过请求比上次访问通知屏幕最近发布的内容的行计数来获得，而单个通知将通过更详细的查询生成当您访问通知屏幕时。这种方法不需要写入或额外的存储空间，但是不灵活，可能会严重影响服务器。
设定
后端（由先前的开发人员建立）使用CodeIgniter和MySQL数据库。它目前在糟糕的GoDaddy共享托管帐户上运行，但我认为（希望吗？）在我们投入生产之前，将对其进行升级，并且托管软件包将随着用户的增长而扩展。
目前，我们唯一的前端是移动应用程序，但我们计划稍后再建立一个网站。我现在不关心从服务器获取有关通知的实时推送更新。
附录
我不专门研究后端，而我在那个部门负责。客户知道这一点，并且我已尽力解释这种性质的项目的范围，但是他们已经明确表示，在这一点上，他们将不信任任何其他人来从事该项目。在开始添加测试人员之前，我们可能还要再做一个月的工作，我才能获得任何类型的性能指标。我真的无法估计未来5年我们将拥有多少用户，或者我们将使用什么硬件，但是我认为客户希望有成千上万的用户或更多。
我希望这个问题足够具体，可以在此处发布。如果需要，我可以对其进行优化。请询问您是否有任何疑问，或者我省略了重要的详细信息。
tl; dr
- 当所有用户都只跟随数百人时，数据库驱动的通知系统是否会对长期可扩展性产生负面影响？
- 有没有一种方法可以使通知由数据库驱动，而无需为每个关注者的每个通知单独的通知行？
- 完全由查询驱动的通知系统是否具有可伸缩性，或者除了不向数据库写入任何数据以外，还具有其他优点？
- 我想得太早了吗？我是否应该仅构建一个目前可以使用的产品，并且由于客户预算有限并且我们不知道最终产品是否会流行，如果问题出现，我们可以担心对其进行优化吗？