在远程进程响应刚刚收到的消息之前，它还需要在本地执行一些工作，因此我们不能假定处理是瞬时完成。只考虑网络延迟还不够，因为远程进程执行的操作也不是立即完成的。此外，我们还无法保证消息送达后会立刻被处理。消息可能会进入远程服务器的等待队列中，等到所有更早到达的消息处理后才被处理。

节点可能相距很近，也可能很远，各节点可能有不同的CPU、内存和磁盘配置，可能运行不同的软件版本和配置。我们不能期望它们以相同的速度处理请求。如果完成一项任务需要等待几个工作的远程服务器响应，则整个执行的完成时间取决于最慢的服务器。

与普遍存在的看法相反，队列容量并非是无限的，堆积更多的请求不会对系统有任何好处。当生产者产生消息的速度大于消费者能够处理的速度时，我们可以使用背压（backpressure）策略减慢生产者的速度。背压是分布式系统中人们了解和应用最少的概念之一，通常是事后才建立，而不是将其视为系统设计必需的一个组成部分。

尽管增加队列容量听起来像是个好主意--可以帮助我人管道化、并行化以及有效地调度请求，但是，如果消息仅仅是停在队列中等待处理，什么也不会发生。增大队列大小可能对延迟产生负面影响，因为这并不会改善处理速度。

通常，进程本地队列是用于实现以下目标：

解耦--使接收和处理在时间上分开，并各自独立发生。

流水线化--不同阶段的请求由系统中独立的部分处理。负责接收消息的子系统不用阻塞到上一条消息处理完成。

吸收瞬时突发流量--系统负载可能经常变化，但是请求到达的间隔时间对负责处理请求的组件是隐藏的。总体的系统延迟会由于排队而增加，便这通常仍比响应失败并重试请求更好。

队列大小取决于工作负载和应用程序。对于相对稳定的工作负载，我们可以通过测量任务处理时间以及各任务的平均排队时间来确定队列大小，从而确保在提升吞吐量的同时，延迟仍保持在可接受的范围内。在这种情况下，队列大小相对较小。对于不可预测的工作负载，可能会出现任务提交的突发流量，这时队列大小也应当考虑突发流量和高负载。

即使远程服务器可以快速地处理请求，也并不意味着我们总是能获得正面的响应。它也可能回应一个失败：无法进行写操作、要查找的值不存在或是触发bug。总之，即使是最顺利的情况也需要我们的关注。