Note on System Design Interview: Part2
Notification System
这里应该还可以包括 chrome notification:
这里的要点是：
- 有一个软实时更新的系统，不要求实时发送，不过也最好不要把推送给用户的内容晚了太多
- 能够 scale, 并推给不同类型的端，比如 iOS, iPad 等
这里应该要设置一对多的 user: device 表，作为用户存储信息的表，然后可以准备一个 cache.
有这个信息后，如果收到一条消息，可能要慢慢把消息丢给 user 的各个 device 或者一些 device, 这里可以用 mq 来解耦这个过程：
这里 worker group 需要 talk from queue, 然后开始消费。这里因为消息不能丢，所以也要持久化处理情况：
当然，这里还要注意 rate limit, retry 和 queue 状态的监控。
News Feed System
News feed is the constantly updating list of stories in the middle of your home page. News Feed includes status updates, photos, videos, links, app activity, and likes from people, pages, and groups that you follow on Facebook
又叫喂猪系统。
这里提供了几个 api:
- Post service (包含 post cache): 正常发文/读文章的服务。
- Fanout service: push new content to friends’ news feed. Newsfeed data is stored in the cache for fast retrieval. (感觉还是要写到 SQL/NoSQL 里面的，得防止丢数据)
- Notification service: 我们上一节吹逼做的那个
用户发文的时候，可能要读扩散写扩散搞到 feed system 里面。给关注自己的人推消息。话说这个 ddia 应该讲了。这里可以只存 <post_id, user_id >, 然后找到 db 里头。
上述是写入的 pipeline. 查询的话就是把大 v 的文章和自己 feed 里面的 merge 一下就行：
话说这里还列了 cache type, 其实挺有意义的：
还可以参考：
- https://www.zhihu.com/question/20690652
- https://developer.aliyun.com/article/224132
- https://www.facebook.com/help/327131014036297/
Chat System
Chat System 的要点是：
- 可能需要保持状态、长连接（这里使用了 ws 实现）
- 网络不好的时候，避免频繁的状态变化
- 对话肯定要持久化，但是不同的用户可以连接在不同的机器上
- 也有些东西不需要长连接
这里登陆之类的使用了无状态的 api, 然后用 ws 维护连接。登录状态用心跳包维护，避免过度 reset。
人与人聊天，人与组聊天使用序列的 id, 这个因为可以 sharding 所以代价不高。一条消息，先持久化存储，然后 fanout 给对话对象（或者 notification system）
这里端需要维护自己的 max_seq_id, 然后重新登录的时候，能够拉出一批数据。
而群聊可以用推模式或者拉模式来实现。对于小群推就推了，否则也可以拉。
登录推送(QQ 微信没有，steam 有)可以 fanout 类似的逻辑来维护