dd家的系统设计题库不大，今天聊聊最高频的原题之一。

题目要求

这道系统设计题是设计一个类似 DoorDash 的 Review & Reward System。用户完成外卖订单之后，可以针对餐厅提交 review，包括 1–5 星评分、文字评价以及可选的图片。用户认证和订单管理等基础服务都假设已经存在，因此不需要设计完整的下单和配送流程，重点放在 review、vote aggregation 和 reward workflow。

Review 发布之后，其他用户可以对这条评价进行 upvote 或 downvote，表示这条 review 是否 helpful。同一个用户对同一条 review 最多只能投一次票，同时系统需要维护 upvote count、downvote count 和 helpfulness score 等聚合数据。用户浏览餐厅评价时，需要同时展示这些统计信息，因此 review retrieval 是一个典型的 read-heavy 场景，需要支持较高 QPS 和较低延迟。

Vote aggregation 还会作为后续 reward calculation 的输入。系统已经存在一个黑盒的 Reward Scoring Service，可以根据 review 质量和 voting statistics 计算 reward amount，因此不需要设计具体的评分算法。需要解决的是如何在 review 到达指定 evaluation window 后可靠触发 reward calculation，并保证每个符合条件的 review 只触发一次。最终 reward payout 由第三方 payment provider 负责，不在设计范围内。

非功能需求主要是 high availability、low latency 和 horizontal scalability。Restaurant review retrieval 最好控制在 200ms 以内。Vote statistics 可以接受 eventual consistency，不要求每次投票后立即反映最新 count。另外所有写接口都需要考虑客户端 retry，因此需要提供 idempotency guarantee。

解题思路

整体可以拆成 Review Service、Vote Service、Vote Aggregation Pipeline 和 Reward Orchestrator 四个核心模块。用户提交 review 时，Review Service 先通过 Order Service 验证订单已经完成，并检查该订单是否已经创建过 review。Review metadata 可以存储在 DynamoDB 或 Cassandra 中，图片放到 S3，只在 review record 中保存 object URL。创建接口通过 idempotency key，或者 order_id 和 user_id 的唯一约束处理客户端重试。

Review retrieval 是主要的 read-heavy path。可以按照 restaurant_id 建立索引，并根据 created_at 或 helpfulness score 排序，通过 cursor pagination 返回结果。热门餐厅的 review summary 和第一页结果可以缓存在 Redis 中，Review DB 作为 source of truth，从而减少数据库读取压力，把 P99 latency 控制在要求范围内。

Vote Service 单独负责投票。Vote table 可以使用 review_id 和 user_id 作为唯一 key，从数据模型层面保证一个用户对一条 review 最多只有一个有效 vote。如果允许修改投票，例如从 upvote 改成 downvote，可以使用 conditional update 更新原来的记录。Vote 写入成功后发布 VoteChanged event 到 Kafka，不需要同步更新 review 的聚合字段。

Kafka 后面由 Vote Aggregator 消费事件，根据 vote change 计算对应的增量，再更新 ReviewStats Store。Upvote count、downvote count 和 helpfulness score 都可以作为异步维护的 materialized view。读取 review 时直接读取预聚合结果，而不是扫描 Vote table 做实时 COUNT，这样可以明显降低 read latency，也更容易水平扩展。由于题目允许 voting statistics eventual consistency，因此短时间的数据延迟是可以接受的。

Reward workflow 可以采用异步调度。Review 创建时记录 evaluation_at，例如 review 发布七天后进入 reward evaluation。到期 review 可以通过 delayed queue、scheduled job 或按照时间分桶的任务表找到，然后交给 Reward Orchestrator 调用 Reward Scoring Service。

Exactly-once 是这里比较重要的设计点。实际实现中可以把问题转化成 at-least-once delivery 加 idempotent processing。Reward Orchestrator 为 review_id 和 evaluation_window 建立唯一的 reward job。Worker 获取任务时，通过 conditional write 将状态从 PENDING 修改成 PROCESSING，成功调用 Reward Scoring Service 后再写成 COMPLETED。如果消息重复投递或者 worker crash，唯一约束和状态机可以避免生成第二个有效 reward job。如果 Reward Scoring Service 支持 idempotency key，还可以使用 review_id 加 evaluation_window 作为 key，让下游调用同样能够安全 retry。

最后需要考虑 failure handling。例如 Vote Aggregator 更新数据库成功但 Kafka offset commit 失败时，消息可能被重复消费，因此需要使用 event_id 去重或者保证 aggregation update 幂等。Reward Worker 调用 scoring service 后发生 crash，可以依靠 idempotency key 重新调用。Redis 不可用时则 fallback 到 persistent store。整体通过 cache、materialized aggregation 和 event-driven architecture 将 read、vote 和 reward workflow 解耦，从而满足高可用、低延迟、eventual consistency 和水平扩展的要求。