题干与适用场景
请设计一个多租户 Consent Receipt Ledger，记录用户同意、撤回和处理目的变更，并支持审计查询。题目适用于系统设计、隐私工程和平台基础设施面试。重点是把同意记录建模为可追溯事实，而不是一个可覆盖的布尔字段。
面试官考察点
- 能否定义同意事件、目的版本、数据类别、证明材料和撤回语义。
- 能否保证租户隔离、追加写完整性、幂等和可验证的查询结果。
- 能否处理撤回向下游传播、延迟消费者、失败重试和历史更正。
- 能否在隐私最小化、可审计性、查询性能和保留期限之间做取舍。
回答前需要澄清的问题
先确认主体是终端用户还是企业管理员，同意范围按目的、数据类别、地区还是处理者区分。问清峰值事件量、查询维度、审计时限、跨区域存储、撤回是否即时生效，以及下游系统是否能回执。还要明确是否需要机器可读导出、法律冻结、删除请求和租户自带密钥。
30 秒回答框架
“我会用版本化目的和追加事件流记录每次授予、更新、撤回与传播结果。写入路径按租户分区并幂等，读取路径返回截至某个时间点的有效状态和证据链。撤回通过可靠消息通知下游，失败进入重试和人工复核。加密、最小字段、租户密钥和保留策略共同限制泄露风险。”
分步骤深入解答
- 领域模型：定义主体、租户、目的版本、数据类别、同意来源、语言、时间、证明文本和状态转移。
- 写入与完整性：采用追加事件和单调序列，使用请求幂等键；哈希链或签名防止静默改写，并将密钥轮换与租户隔离分开。
- 状态读取：由事件投影生成按主体和目的查询的当前状态，同时保留事件位置、投影版本和证据引用。
- 撤回传播：把撤回发布到下游处理者，记录每个接收者的确认、重试和最终失败，不把“已发送”冒充“已停止处理”。
- 运营与治理：设置分区、冷热存储、访问审计、删除与法律冻结优先级，提供租户授权的导出和分页查询。
高质量示范回答
我会把账本分成不可变事件层、可重建投影层和受控证据存储。事件至少包含租户、主体标识的不可逆引用、目的与版本、数据类别、动作、来源、时间、策略版本和请求幂等键；原始同意文本或界面快照放在加密存储，不直接暴露给普通查询。每个租户有独立分区和密钥范围，事件按租户序列追加，使用哈希链和签名检测静默修改。查询服务先读取投影得到某时刻的有效状态，再返回对应事件位置和证据引用。撤回事件进入可靠队列，按下游处理者逐一追踪确认；超时或拒绝会重试并升级，状态明确区分已记录、已发送、已确认和失败。事件投影可从账本重放，支持目的版本变更和历史更正。最后以租户隔离测试、重复请求、乱序事件、密钥轮换、撤回延迟、导出权限和删除冻结演练验证系统。
常见错误
- 只保存
consent=true，覆盖了目的版本和撤回历史。 - 把下游通知成功当成下游已经停止处理。
- 用可编辑数据库行替代追加事件，无法证明历史是否被改写。
- 在全局索引中放置可识别主体或租户信息，破坏隔离与最小化。
- 只设计写入，不说明乱序、重试、投影重建、删除和法律冻结。
追问及应对
用户重复点击同意怎么办？
用请求幂等键和事件指纹去重，但保留来源或界面版本变化等有意义的更新。查询返回最终状态，同时能追溯被合并或忽略的请求。
目的版本变更需要重新同意吗？
把目的文本和版本作为不可变引用。若新版本扩大处理范围，就产生待重新同意的状态；不能把旧版本的同意自动套用到新目的。
账本如何支持删除请求？
先区分必须保留的审计证据与可删除的主体数据，使用不可识别引用和加密擦除降低风险。法律冻结优先于普通删除，并把删除范围和例外记录为受控事件。
如何证明查询结果没有漏事件？
返回租户序列范围、投影版本和事件校验摘要。审计工具可从事件层重放同一时间点，与投影结果比对并报警。