老师，最近在面经里看到一道这样的设计题“Design “stories” (like Instagram and Whatsapp). Stories disappear after friends view them, and are only available for 24 hours after publishing”. 这个功能应该怎么在我们之前说的Instagram的框架下实现呢？
1 个赞
有两种阅后即焚，一种是 Instagram Story，24小时内可以反复看，之后 Expire。另一种是 Snapchat message，接收方只能看一次，之后就 Expire，如果没人看，一段时间后删除（Snapchat 服务器保留30天）。
如果说24小时内反复看的这种，对于每一个 Fanout 的 Story 在用户读取时需要看时间戳，如果超过时间就删除。另外还需要一个 Reaper Process 去把过期信息删除节约数据库空间，加快读取速度。
谢谢老师，对于Snapchat那种阅后即焚，是说推送给了用户，用户看过之后，会回一个message给server表示这条信息已经读过，然后把这些request放在一个queue内，在服务器侧做删除吗？
另外，这种只有24小时的数据的feed table还需要存在数据库里吗？还是说Redis也可以？Redis的Key可以是userId，value可以是一个list of tweet。
PS，如果是正常Instagram的feed table能否考虑存Redis呢？ 存Table的话会比存Redis慢，而且Feed如果一直不读，也挺浪费空间的。Redis的list可不可以只保留最近500条feed这样，之前的就pop出去。
阅后即焚的话，一个用户看过消息后，消息标记读过以后，本地会先记录，然后发送到服务器。显示消息的时候也会先看本地的记录，这样避免服务器端的 race condition。服务器端定期删除所有的已读信息，可以 batch 处理，不需要放 Queue。
对于只需存24小时的数据，我们需要知道这些数据在这24小时内的可靠性需求高不高，如果丢数据影响大吗。虽然 Redis 有备份机制，但数据可靠性不如数据库。如果允许丢数据，那么 Redis 方案可行。
普通的Feed table 我们课上讨论了用 Query Cache。你说的每个人保留500条Feed肯定能降低延迟，但代价也不小，你可以计算一下存储这些 Feed 所需的内存。