为了提供流畅的用户体验，Web服务的响应时间至关重要。但是随着系统规模和复杂性越来越大，用量不断增加，控制延迟分布的尾部不致过长也越来越难。在中型系统中不太令人注意的暂时的高延迟情况，会对大规模系统的总性能产生巨大影响。与过去系统复杂性达到一定程度后，无错运行不再可行而发展出容错技术类似，现在完全消除引起响应时间波动的来源，对于大型服务来说也不再可行，于是容延（latency tail tolerant）技术应运而生。
Google两位Fellow Jeff Dean和Luiz Barroso合作，撰写了名为“The Tail at Scale”的论文，比较系统地阐述了容延技术。

首先，引起响应时间波动的原因很多，涉及软件和硬件：共享资源、后台驻留程序、全球资源共享、维护、排队、电力限制、垃圾回收和电源管理等。而由于大规模系统中普遍采用并行，一项任务会分为众多子任务由众多组件完成，导致放大效应，因此单个组件出现响应时间波动的概率即使很低，也会大大影响整体性能。（参见《程序员》2013年3月刊《Just Works的力量》）

显然，通过在各层次、各组件中使用超额资源配置、精心进行软件实时设计以及提高可靠性，都可以缓解引起响应时间变化的问题。其中，组件级的容延技术包括：设置不同服务级别，使用更高层的排队机制；减少队首阻塞；管理后台活动，同步处理。缓存无法直接解决延迟问题。

但相比之下，通用的容延技术更强大。Google将自己的经验总结为两类：

•第一类是几十毫秒级的请求内短期调整，主要适用于大多数操作都针对只读、一致性不强的数据集。手段包括对冲请求和关联请求。
•第二类是几十秒到分钟级的跨请求长期调整，针对更细粒度现象导致的延迟波动。手段包括微分区、选择性复制和延迟引导的察看。
而对于速度至关重要（缓慢地返回最优结果，不如迅速地返回次优结果）的大型信息检索系统，可以采用的技术是：“够好就行”（good enough），只要有足够数量的子服务器返回结果即可；金丝雀请求，在向所有子服务器请求之前，先找一两个测试一下，如成功才发送。

文章还指出，对于要改关键状态的操作，其实延迟问题更好解决，因为规模一般不大，而且有更直接的办法。而对于频繁的写操作，基于quorum的算法如Paxos是常用技术。

未来，作者认为硬件层面带来的变化因素会更多，因为硬件设备的异构性将愈演愈烈，而系统规模还会继续增大。这样，通过软件来实现容延技术也会越来越重要。但硬件也会带来好的一面，数据中心网络中更高的等分带宽和网卡的优化都会减少关联请求的成本，取消信息更可能及时收到从而减少冗余工作。

最后，虽然一些高效的容延技术需要增加资源，但开销并不大。它们所依赖的往往是现有容错能力，所得到的延迟改善效果却非常可观。此外，这些技术多数能封装在基本库和系统中，而且延迟改善还往往能极大地简化应用程序级设计。除了能够带来大规模延迟降低，这些技术还能在不牺牲服务响应性的情况下实现系统的更高利用率。