题目重点：从用户写到日志、索引和持久数据，定义写放大并推导崩溃和扩容路径。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 明确engine级拆存储、写路径、恢复、一致性，讨论写放大和云扩展。未给引擎算法，练习从单分片有序KV或事务页存储选择起点，不把二者混成具体Aurora实现。
- 先定键/事务范围、写速率、数据量、durability和恢复目标，再选择页更新、日志、buffer与后台整理。所有量级例子是练习预算。
解题路线
- 画出接收→校验→冲突控制→记录日志→持久确认→更新可见数据→后台flush/整理。每条边说明失败后由谁恢复，不能只画组件名称。
- 写放大定义物理写字节/逻辑用户写字节，日志、索引更新、页重写、整理和复制是否计入需一致口径。读放大和空间放大另列；降低一项可能提高另外两项。
- 后台工作需要预算，否则持续写会让flush/整理积压并影响前台尾延迟。根据积压、可用空间和恢复时间给背压/节流，而不是仅加无限buffer。
- crash recovery验证已确认写可恢复、未确认写结果可查询、半记录可识别、重复replay不重复副作用。扩容时迁移一个明确key范围，版本/fencing保证旧新owner不同时写，切换前追平日志。
手动走一遍
逻辑100MB/s，若日志100、页/索引重写200、整理300MB/s，口径内物理600MB/s即6倍；再计三副本要按传输/物理写定义另列，不能重复算。恢复需要读取200GB日志时，以1GB/s纯顺序扫描的200s只是下界，页IO与重放还会增加。
规模与取舍
容量预算包含前台写和后台写；100MB/s逻辑不代表盘只需100MB/s。恢复时间约日志扫描+重放IO/CPU，在线扩容受迁移和追增量速率差限制。
易错点与追问
容易失分的边界
- 不同指标混算得到虚假低写放大。
- 后台积压无上限，磁盘最终用满。
- 扩容copy结束即切主，未追平增量且未fence旧writer。
继续深挖
- 若写入速度大于迁移追平速度，如何保证切换完成？
- 怎么把RTO约束转为checkpoint频率及日志保留预算？
