内容审核怎么选：先审后发，还是先发后审 UGC 平台的内容审核有两条路：先审后发 vs 先发后审。 在讨论技术方案之前，先要问产品和法务：这个平台能承受多少风险窗口？ --- 两种策略的核心权衡 先审后发 用户发布内容 → 进入审核队列 →

实时热榜怎么设计：Redis ZSet 与热度分值 接到需求：展示实时热榜，按热度降序，支持分页，每分钟刷新。 第一反应：SELECT id, score FROM post ORDER BY score DESC LIMIT 20，不就完

互关状态怎么保持同步：双向关系的维护与缓存失效 A 和 B 互相关注，UI 上都显示"互相关注"。 A 取消了对 B 的关注，A 那边显示变成了"已关注"（单向），但 B 打开 A 的主页，居然还显示"互相关注"。 数据没同步，B 看到的是

并发点赞的计数设计：原子操作与最终对账 并发点赞有一类经典现象：压测时点了 50 次赞，最终计数却少了几个，而且稳定复现。 少掉的计数去哪了？ --- 错误方案：读-改-写 并发时：线程 A 读到 50，线程 B 也读到 50，都写回 51

删了父评论，子评论怎么处理——先想清楚用户看到的是什么 产品来问：用户举报了一条评论，审核通过后要删除它，但这条评论下面有 12 条回复，删除父评论后，这 12 条回复怎么办？ 这不只是个数据库问题，首先是个产品问题：用户看到的页面里，这

定时消息任务触发了两次 用户反馈说收到两条一模一样的活动提醒，发送时间相差不到 1 秒。 看日志，这条定时任务的执行记录出现了两次，两次都显示"执行成功"。 不是 MQ 重投的问题，定时任务根本没走 MQ——是调度器直接触发的。 --- 分

消息量大，写扩散还是读扩散——接到这个需求先问清楚规模 做站内信、Feed 流之前，先问一个问题：这个平台上，关注量最大的用户大概有多少粉丝？ 答案决定了架构方向。 --- 写扩散（Fanout on Write） 用户 A 发了一条动态，

同一条消息推送了三次 用户反馈：刚才连续收到三条一模一样的推送通知。 日志里能查到这条消息，确实发送了三次——每次间隔大概 2-3 秒，内容完全一致。 --- 根源：MQ 的 at-least-once 语义 消息队列默认保证"至少送达一次

活动结束了，用户还在收短信 活动 8 点准时结束，但到了 8:05，用户还在陆续收到活动相关的短信通知。 运营觉得奇怪：代码里已经判断了"活动已结束不发短信"，为什么还在发？ 原因不在判断逻辑，在任务队列里。 --- 任务已入队，判断在消费

接到注销需求，先问两个问题 用户注销账号——这个功能听起来不复杂，无非就是删掉数据。 但在动手之前，两个问题必须先问清楚：数据删到什么程度？ 注销后用同一手机号重新注册，老数据要不要继承？ 这两个问题的答案，决定了整个方案的走向。 ---