题目重点：设计开发者社区的身份连接、帖子互动与关注Feed，防止外部API故障阻断站内功能。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 只有GitHub user社区设计方向，没有具体功能或TPS。练习让用户连接外部开发者身份，发帖、关注、评论和浏览Feed；代码托管不是本题默认范围。
- 外部GitHub身份或公开项目数据通过授权和缓存同步；不把外部access token当本站登录session，不假设无限API配额。
解题路线
- 本站User与ExternalIdentity分开，绑定通过明确验证；public profile缓存可过期刷新，private项目访问仅按授权范围，不因外部API返回过就长期公开。
- 帖子、评论、反应为权威内容对象，编辑和删除带版本并发事件；Feed只存contentId和排序信号，读时检查当前权限/删除状态，避免推送时的旧权限泄漏。
- 关注图支持关注/取消；小作者fanout on write，大作者fanout on read或混合。外部项目更新先进入缓冲队列限流和去重，不让供应商API超时直接阻断发本站帖子。
- 站内内容spam和冒充风险用rate limit、审核队列和身份标识处理；“有GitHub账号”不是内容真实性证明。按查询需求区分近期Feed与全文搜索。
手动走一遍
作者删私密项目相关帖子时，Feed缓存仍有ID，但读路径依据版本/权限不展示正文。外部API被限流，界面显示profile更新时间，站内发帖仍成功；后台重试不反复创建同项目通知。
规模与取舍
练习100万DAU、平均每人读20次为2000万读/日约231/s平均，峰值、Feed候选和对象字节另估。fanout成本取决于作者粉丝数，不靠DAU单独决定架构。
易错点与追问
容易失分的边界
- 默认所有外部项目数据公开且可永久缓存。
- 仅Feed删除事件到达后才保护隐私。
- 外部API故障影响全部站内写操作。
继续深挖
- 如何让用户解绑外部身份并删除相关token？
- 明星作者突发发帖如何防写放大与读热点？
