如何为基于Firebase的交友App构建可扩展的NoSQL后端架构

你的方案在产品逻辑上符合需求，也确实能实现基础的每日分发规则，但存在几个可优化的结构问题：

• 预生成大量池文档的方式存储冗余极高，且随着用户量增长，文档数会持续膨胀，后续查询和存储成本会快速上升
• 去重逻辑效率低：将用户ID写入预生成文档的子集合标记已浏览，不仅单次浏览就要产生1次写操作，还存在同一个用户profile出现在多个预生成文档中导致重复推送的风险
• 分发公平性不足：随机取未浏览文档的逻辑会导致靠前的预生成文档曝光率远高于后置文档，后续新增的用户profile很难被老用户刷到
• 容错性差：如果出现用户注销、账号封禁的情况，预生成文档里的无效引用需要额外做校验，进一步提升了读写消耗

数据库结构调整 #

保留原有singles用户集合，调整分发相关的存储结构：

• 新增3个独立的单文档候选池：male_pool、female_pool、mixed_pool，每个文档内仅存一个数组，存放对应用户的userId，无需生成上百个独立文档
• 给每个singles下的用户文档新增3个下标字段：last_male_index、last_female_index、last_mixed_index，记录用户上次取对应候选池内容的位置；同时新增viewed_profiles数组，存储用户已经浏览过的profile ID，长度上限控制为2000条即可，足够覆盖一年以上的浏览去重需求
• 新增likes子集合，路径为singles/{被点赞用户ID}/likes/{点赞用户ID}，同时给用户文档加received_likes数组存储点赞者ID，用于首页展示“喜欢你”的用户列表

分发逻辑优化 #

• 用户请求当日4个profile时，直接从对应用户偏好的候选池数组中，从上次记录的下标开始向后遍历，跳过已经存在于viewed_profiles的ID，取满4个后更新用户的对应下标字段，同时将这4个ID写入viewed_profiles。整个过程仅需1次批量读（读取候选池文档+用户自身文档）、1次写（更新用户的下标和浏览记录），相比原方案读写成本可降低80%以上
• 仅保留每周1次的定时任务，作用是打乱3个候选池的数组顺序、清理池中的无效（注销/封禁）用户ID，无需每日运行定时任务生成文档，大幅降低调度消耗
• 点赞匹配逻辑：用户点赞时仅需写入对应likes子集合文档，同时更新被点赞用户的received_likes数组；当被点赞用户回关时，直接给双方用户文档的matches数组新增对方ID，同时创建chats集合文档开启聊天即可，全程最多仅需3次写操作

额外成本优化建议 #

• 开启Firestore本地持久化缓存，用户的个人文档（浏览记录、收到的点赞、匹配列表）默认走本地缓存，仅增量更新时请求服务端，可再降低50%以上的读操作消耗
• 当用户的viewed_profiles数组长度超过2000时，自动删除最早的1000条记录，避免单文档体积过大影响查询效率，也不会影响日常去重逻辑

内容的提问来源于stack exchange，提问作者Sishir Mohan