支持注册登录的TODO类应用后端架构如何设计？

对于普通TODO待办这类面向普通C端用户的工具类应用，直接选单数据库+记录关联用户ID的方案即可，给每个用户单独建独立数据库属于特殊场景才用的方案，初期完全没必要考虑。

单数据库+用户关联字段方案（常规首选） #

这是行业内用户类应用的标准实现，逻辑简单且扩展性足够：

• 表结构设计成本极低：只需要建两张核心表，users表存用户注册信息、登录凭证哈希，todos待办表增加user_id字段作为外键关联users表主键，所有待办查询都带上WHERE user_id = 当前登录用户ID的过滤条件，就能实现用户数据的逻辑隔离
• 运维成本极低：全程只需要维护一套数据库实例，备份、扩容、版本升级、故障排查都只针对单实例操作，不需要额外开发动态建库、动态切换数据源的冗余逻辑
• 功能扩展灵活：后续要做待办共享、全局数据统计、平台管理后台这类跨用户功能时，直接单库写SQL查询即可，不需要做跨库数据聚合的复杂操作
• 性能冗余足够：常规MySQL实例单表承载千万级待办记录毫无压力，只要给user_id字段建好索引，单个用户查询自身待办的响应速度可以稳定在毫秒级；真到了用户量破百万、单表数据破亿的规模，再迭代做分库分表也完全来得及，初期不需要为了远期可能不存在的规模过度设计。

单用户独立数据库方案（仅特殊场景适用） #

这个方案本质是物理级别的强数据隔离，适用范围非常窄，只有两类场景值得考虑：

• 面向高合规要求的B端大客户做定制化交付，比如服务金融、政务类客户，合同明确要求客户数据必须物理独立存储，不能和其他租户数据混存
• 单用户本身会产生超大规模数据，比如单个用户就要存储数百GB的业务数据，和其他用户混存会明显拖慢整体查询性能
  对TODO这类轻量工具来说，这个方案的缺点完全无法接受：
• 开发复杂度陡增：需要额外实现用户注册时动态建库、初始化表结构、动态路由数据源的逻辑，还要维护每个用户和对应数据库的映射关系
• 运维成本随用户量线性暴涨：如果有1万注册用户就要维护1万个数据库，备份、故障修复、版本升级的工作量会直接翻上万倍，还很容易出现数据库连接数被打满的故障
• 跨用户功能实现成本极高：要做全站待办完成率这类统计时，需要遍历所有用户的数据库拉取数据再聚合，效率极低。

初期落地避坑提示：
所有待办相关的查询、修改操作，必须从服务端保存的登录态里取当前用户ID做过滤条件，绝对不能信任前端传参传入的用户ID，避免出现越权访问其他用户数据的问题。

内容的提问来源于stack exchange，提问作者Filip Páral