题目重点：从投票创建、候选项、投票提交和结果查询设计 API，明确一人一票与匿名性为训练假设。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练场景为组织内单选投票：一位有资格用户对一场开放投票只能提交一张票；投票关闭后不可修改；匿名对外展示聚合结果。
- 题目未明确是否允许改票、多选、弃权、投票公开性或审计法规；这些直接影响 schema 与接口，面试开头必须追问。
解题路线
- 资源分为 poll、option、eligibility、ballot 与 aggregate。`POST /polls` 创建草稿，`POST /polls/{id}/open` 开始，`GET /polls/{id}` 查规则；写操作用授权控制。
- `PUT /polls/{id}/ballot/me` 提交 option_id 与 Idempotency-Key。数据库以 `(poll_id,voter_id)` 唯一约束和事务校验开放状态及资格；同 key 重试返回同结果，重复投不同选项按训练规则冲突。
- 投票成功的主存是真实 ballot，计数可通过同事务更新或异步聚合。`GET /polls/{id}/results` 明确是精确快照还是最终一致，关闭后可生成稳定终稿。
- 鉴权日志与可见结果分离；权限管理者可能需要审计投票资格，却不应让普通读取接口泄露某用户所选。限流、防刷与撤销资格后的规则需在契约中写清。
手动走一遍
用户 U 对投票 P 提交选项 A，网络超时后以相同 idempotency key 重试，服务器返回原 ballot 版本，计数仍加一次；若改用不同 key 投 B，训练契约返回 409。管理员关闭 P 后再提交则返回不可写状态。
规模与取舍
写请求索引查资格与唯一 ballot 通常 O(log N)，聚合可读预计算 O(1) 每选项，但存储与更新成本随投票数和选项数增长。高并发热点计数可分片汇总；结果延迟和最终一致窗口须对客户端显式标注。
易错点与追问
容易失分的边界
- 仅在应用层先查‘未投过’再写，竞态下重复投票。
- 重试重复给计数加一。
- 用公开结果接口暴露 voter_id 到选项映射。
- 未定义关闭瞬间与并发提交的事务序。
- 把单选/不可改票当作题目明示约束。
继续深挖
- 若允许改票，计数和 ballot 历史如何事务更新？
- 匿名投票同时要求可审计资格，身份与选择怎样分离？
- 数百万用户同一秒投票怎样削热点？
- 投票结果应实时可见还是仅结束后可见，怎样防止中途结果影响投票？
