Discord 系统设计图发出来后，评论区先问 Redis TTL

Suni 在 X 发了一张 Discord System Design 架构图，配文只有这一句。图用 Excalidraw 画的，这是他在回复里说的。图如下：

评论区里 Franciele 提了一个具体问题：presence 存 Redis 并设 TTL 有风险，用户还连着，状态会不会先过期消失？这条没有展开。后面有回复说“No, it's not”，也有人只回 Important。另一个网友说，做了十年，消息有时候还是会消失。还有人调侃所有东西都得用 Rust 重做。

这些回复比图本身更有意思。系统设计图容易画成方框和箭头，真正上线后先出问题的常是过期时间、在线状态、消息可达性这些边界。presence 放 Redis 不奇怪，TTL 也不奇怪，麻烦在 TTL 和连接生命周期怎么对齐。连接还在，状态先没，用户看到的就是“我明明在线，别人看我不在”。这类问题不靠架构图回答，靠心跳、续期、断连回调和降级策略。

Suni 的推文还引了一个外链，标题是 Instagram system design: a fan and a star, then one story to 184 friends。外链把一次关注、看 Story、点赞、评论拆成调用顺序。几个细节值得看：Virat 的主页读 Memcache，不直接压数据库；关注写两行，分别落在两个用户的分片；Story 对普通用户做写扩散，184 个粉丝就写 184 个 tray，对 2.73 亿粉丝的账号改成拉取，不复制；点赞计数拆成多个小计数器，读时再加；通知按时间窗口合并，不逐条推送；评论先过 Safety 再落库。外链还提到，Story 的观看记录写 Cassandra，一百万观看就是一百万行，不会变成一百万条通知。

这些细节和 Discord 图下的 TTL 问题是一类事：读写路径、缓存、过期、计数、通知聚合，决定系统在真实用户手里是否成立。图好看是入口，评论区那个问题才是继续往下看的钩子。

外链：https://sd-for-rookies.tech/instagram