邮件设计_性能与健壮性的博弈

今天发生了一件事情：发给用户的邮件有问题。一番排查之后：问题找到了;
下一步就改考虑补救措施了，很遗憾，当前的设计不支持

当前设计目标：以降低数据库压力为首要目标

 用户需要的数据，全部都包含在邮件里边了
 用户无论打开什么时候的邮件，都只需要给邮件服务器交互
 数据库可以清除发送过后的数据，始终保持轻量，读写性能有保障

问题：数据库的数据更新后，邮件内容无法更新

解决方案：从数据库获取最新值，但是需要解决以下问题

 直接从数据库获取，数据库压力大，走缓存？
 需要更新时，如何快速的清除用户缓存？
 单表数据容量有限，分表？怎么灵活的创建下一次需要用到的表？
 单库数据容量有限，分库？
 分库分表后，用户要查历史数据，路由如何设计？