message service high -level design为啥client和websocket server用一根弧线直接连接（绕过可gateway+lb+firewall）
1.7里面接口设计，msg的timestamp是谁的timestamp？client发送的时候client端的时间还是服务器收到时候的服务器端的时间？
容灾设计里面把客户端座位source of truth，会不会客户端数据被篡改导致message的双方客户端的数据不一致？
关于课程最后notification那部分没听明白，既然可以用websocket来push信息，为啥还需要 apns ， gcm 之类的。难道手机锁屏的时候websocket就关闭了？
facebook message的队列为啥是存在硬盘里的，这样服务器发送消息不是很慢么？
logic
2021 年4 月 24 日 05:23
2
实际上 Websocket connection 是通过 gateway 的，但只是 pass through。绕过和不绕过两种画法都可以，都有一定的道理也有不清楚的地方，面试中要具体提一下的。Ratelimiter 对超过处理能力范围的 response 可以做 exponential backoff。客户端也可以 retry。
服务器端的 timestamp
这里说客户端来做 source of truth，就是说客户端可以把之前发送过的 Request 重新发送一遍。如果用户黑掉了客户端，那么双方数据肯定会有不一致，但这个就是一个 security 问题了，超出讨论范围了。
手机锁屏显示的 notification 是通过 iOS Android 系统来发送的，不是通过 APP 来发送的。APP 发送的通过 Websocket，系统发送的需要遵循系统的 API，用 APNS, GCM。锁屏的时候不能保证 APP 能跑。
因为队列需要存的时间比较长，数据 durability 要求高，肯定要硬盘备份的。比较新的消息仍会存在内存中，保证大多数情况下速度不受影响 。
第三个数据流（sender和receipt都在线发送seen status）是不是画错了？messge service里面的queue应该是a的queue？
用户状态的子问题我们需要presence db吗还是cache就可以了？这个信息不是每几秒就会通过heart beat更新的么？
关于message table的parition key，我觉得用thread id做partition key没有问题的，我们其实不需要一定把同一个receipet的所有信息都放在一个shard上面，我们只要保证同一个thread里面的message的顺序就可以了。这时候在用户上线pull的时候可能需要所有的server都query一遍，但由于这样的request远远小于push的request，所以我觉得用thread id来shard还是ok的吧？
logic
2021 年5 月 13 日 22:05
4
对，应该放回 A 的 Queue。刚刚在课件里更新了图。
Presence 需要 DB。一个用户可能在好几天以前最后一次上线，我们需要告诉他的朋友他上次上线时间。
Thread ID shard 会像你说的造成需要读取多个 Partition。这样会造成 Latency 增加，是不如按照 recipient shard 来的好的。特别是我们讨论的一对一聊天，没有必要引入 thread 的概念。