对大多数读多写少的业务，Cache Aside 是足够清晰的起点：读缓存，未命中则读数据库并回填；写数据库成功后删除缓存。
为什么通常选择删除
直接更新缓存需要重新计算完整缓存值，也容易遗漏其他写入口。删除让下一次读取从数据库恢复正确值，逻辑更集中。但数据库提交成功、缓存删除失败时仍会产生旧数据，因此删除动作需要重试或写入可靠消息。
处理并发窗口
读线程可能在写线程提交前读到旧值，并在删除后又把旧值回填。可以根据业务容忍度采用短 TTL、延迟双删、版本号或者订阅数据库变更。强一致要求很高时，缓存可能根本不该位于关键判断路径。
缓存设计必须回答三个问题：允许旧多久，缓存不可用时系统如何退化，热点键失效时数据库能否承受。把这三点写进设计文档，比争论某一种模式更有价值。