DoorDash 公开了内部缓存平台 Entity Cache 的技术细节：基于 Envoy 与 Valkey 构建，在服务网格层拦截请求，并用 XFetch 概率算法预测缓存过期、提前刷新——最终支撑起每秒 150 万次请求，可用性 99.99999%。
在微服务架构里，最贵的请求往往是那些重复的请求。50 个服务反复读取同一份不常变更的数据，每次都要穿透完整调用链，消耗计算资源，并在生态扩张时推高尾延迟。
缓存不是新话题，难的是在大规模下让缓存保持新鲜。
每个应用各自实现缓存逻辑，重复请求仍会打到后端，团队维护成本高。
透明代理拦截 HTTP 与 gRPC 请求，命中即返回，未命中才转发上游——服务零改造。
DoorDash 把它描述为「不是单一的优化，而是一组针对可靠性和性能的特性集合」。缓存被搬到基础设施层，由服务网格集中管理。
当一个请求到达 Entity Cache，代理首先向 Valkey 查询是否存在有效缓存。
两条路径，一条通向性能，一条通向正确性。缓存的新鲜度由 Kafka 事件驱动失效机制保障：对比更新时间戳与缓存响应，过期条目被刷新，无需分布式删除。
真正关键的是双重 TTL 阈值——它允许系统在故障期间返回略微过期的响应，而不是直接失败。
阅读提示：两条链路展示了缓存的两种命运——命中时零上游消耗，未命中时才走完整调用链；双重 TTL 是「可用性优先」的设计选择。
这个案例揭示了 Entity Cache 的本质：它把「缓存」从性能优化工具，变成了韧性基础设施的一部分。
阅读提示：四项数据来自 DoorDash 官方博客。前两项是资源效率，后两项是延迟账——2.1ms 是缓存带来的全部代价。
还有一组数据藏在正文里：正常运行期间，上游请求减少 60% 到 95%，新接入端点的延迟改善最高达 90%。
传统 TTL 是一刀切：到期即失效。高峰时段大量条目同时过期，就会形成缓存雪崩。
XFetch 算法改变了这个逻辑——被频繁访问的条目会在到期前被提前刷新，把「同时过期」打散成「分批刷新」，从概率上降低雪崩风险。
这不是等待失效，而是预测失效。
减少内存分配开销，直接贡献 50-60% 的分配率下降。
缓存未命中时合并重复请求，防止重复计算打爆上游。
概率性预测高频条目的过期时间，主动刷新而非被动等待。
阅读提示：三项优化分别解决内存、并发、过期三个问题。XFetch 是其中唯一带「预测」能力的组件，也是 Entity Cache 的 AI 内核。
AI 的价值不只在生成内容，更在于把预测能力嵌进看不见的基础设施。DoorDash 用 XFetch 证明：一个轻量算法，就能让缓存系统在真实故障中保持可用。真正聪明的系统，是那些你感知不到它存在的系统。
DoorDash 对 Entity Cache 的定位