题目重点：定义客户端事件批上报契约、服务端接收语义、去重键和功耗/网络预算。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练版为匿名或用户已同意的应用使用事件采集，不采集消息正文、定位等敏感数据；实际合法字段与保留策略必须按产品规定。
- 客户端可离线且请求可能重试，服务端提供 batch ingest，响应的是持久接收而非最终分析完成。
解题路线
- 接口可设计 `POST /v1/events:batch`，请求包含 app_version、schema_version、batch_id 与每条 event_id、occurred_at、event_type、允许的 properties；服务端返回已接受/拒绝条目及可重试原因。
- 客户端本地有有界队列和批量阈值，遇网络/电量受限延后上传；退出同意后停止采集并按政策处理待上传数据。限制单批大小与重试次数，指数退避加 jitter。
- 服务端校验身份/设备令牌、schema、时间偏差、大小和速率，先写可靠队列再确认；以 event_id/producer_scope 做去重，避免请求重发重复计数。
- 端到端留事件时间和接收时间；跨版本解析与坏事件隔离，远端配置采样时也保证重要错误类事件可观察。事件属性白名单、最小化保留与访问控制优先于‘先全收再说’。
手动走一遍
App 在地铁离线时累计 20 条允许采集的事件，回网后一个 batch 上传。第一次响应丢失，客户端重试相同 batch_id/event_id；服务器可重复回应接收成功，但下游每个 event_id 只入指标一次。
规模与取舍
带宽约为事件平均字节数 × 有效事件率，加上 batch/header 开销；离线本地缓存空间由最大事件数、单条上限与保留时长共同约束。题目无设备量，不能给固定 QPS。
易错点与追问
容易失分的边界
- API 返回 200 就声称所有指标处理完成。
- 无 event_id，离线重发重复计数。
- 逐事件单请求造成电池和网络开销过高。
- 无限本地队列吞掉设备存储。
- 把用户文本或敏感属性装入任意 properties。
继续深挖
- 部分事件无效时整个 batch 失败还是部分接受？
- 客户端时钟严重不准，事件时间如何处理？
- 采样后怎样估计总体指标和置信区间？
- 用户撤回同意后本地和服务端数据怎样处理？
