故障隔离泳道的好处已经超越了通过故障隔离提高可用性的想法。因为泳道把客户或者把跨客户共享的功能做了拆分，当出现故障时，可以更快地定位问题来源。从网络服务器到持久层，如果已经对客户沿Z轴做了拆分，影响单个客户的唯一故障将会很快被隔离在那条泳道里的那组客户。你会对要找的缺陷或问题（由数据或操作触发）了然于胸，因为对于游道中的客户它是唯一的。如果已经沿Y轴进行了拆分，而“购物车”泳道出现了问题，你马上就会知道问题是与构成该泳道的代码、数据库或者服务器相关。事件检测与解决以及问题的定位和解决都明显受益于故障隔离。
故障隔离的其他好处还包括更好的可扩展性、更快的上市时间以及更低的成本。因为我们专注于系统分区，开始考虑水平扩展，所以可扩展性提高。如果通过Y轴隔离泳道，那么我们可以把代码库也进行拆分，这样可以更有效地使用工程师。因此，我们获得到了更大的工程吞吐量，每个单位开发的成本也更低。如果吞吐量越来越大，显然产品推向市场的速度加快。最终所有这些好处使我们能够处理“预期但意外之外的事情”：那些知道迟早会发生但不清楚其后果的事情。换句话说，我们知道事情将要发生，只是不知道会发生什么或何时会发生。故障隔离使我们能够更优雅地处理这些故障。
讨论了为什么应该为产品建立泳道或设置故障隔离，现在我们把注意力转向更重要的问题，如何实现故障隔离。依靠四条原则来定义和帮助我们设计泳道。第一个原则是泳道之间什么都不共享。通常不包括网络组件，如网络入口的边界路由器和一些核心路由器，但包括为故障隔离服务专用的交换机。经常共享一些其他的设备，诸如非常大的存储区域网络或者小网站中的负载均衡器。在任何可能的场合，而且在特定成本范围内，试着尽量不要共享。永远不要共享数据库和服务器。因为泳道的部分定义不共享，所以服务器和数据库共享一直是确定泳道边界所在的起始点。鉴于网络设备和存储子系统的成本问题，有时在系统增长的初期可以考虑跨越不同的泳道。
泳道的第二个原则是在泳道之间不进行同步调用。因为同步调用会捆绑服务，所以被调用服务的失败会蔓延到所有其他以同步和阻塞方式调用的系统。因此，这会违反故障隔离的概念，如果部署在一条泳道里的服务失败可能会导致部署在另一条泳道里的服务失败。
第三条原则限制泳道之间的同步调用。比起同步调用，异步调用失败蔓延到其他泳道的机会很小，但仍然有机会降低系统可用性。突然激增的请求可能使某些系统变慢，例如拒绝服务攻击后发布消息。这些消息铺天盖地阻塞队列，开始占满TCP端口，如果实施不当甚至导致同步请求的数据库处理停滞。因此，我们试图限制跨越泳道界限的事务处理数量。
泳道的最后一个原则是，当绝对必要时如何实现跨越泳道边界的异步传输。简单地说，每次要跨越泳道进行异步通信时，我们需要对事务处理有“不在乎”的能力。在某些情况下，事务处理可能会超时，可以忽略它。我们可能只是“通知”另一条泳道有些行动，并不在乎是否得到回应。在所有情况下，我们应该实现逻辑以实现在手动自动或两者兼有的基础上“断开”或“关闭”通信。监控人员通过系统监控发现故障（手动开关）应该有能力关闭通信，当情况不好时，系统应该能感知并停止（自动开关）通信。
回想一下本书的前言，还记得里克·达尔泽尔提到过亚马逊吗？亚马逊的第一次拆分是把商店功能从订单履行功能中分离出来。如果由于某种原因，亚马逊店面失败，亚马逊可以继续履行已收到的订单。如果订单履行系统出问题，商店可以继续接收订单并把它们放入队列。显然，两个子系统需要互相通信，但从客户角度来看不是“同步”。工作以履行订单的形式从前端传到后端，以订单状态更新的形式从后端传向前端。这种拆分提供了两个好处，故障隔离和更高水平的可扩展性，因为每个子系统都可以独立扩展。
在我们希望故障隔离，但需要同步通信或访问另一个数据源的情况下怎么办？前一种情况下，可以复制需要的服务，然后把它配置在泳道里。支付网关就是这种方法的一个例子。如果我们沿着Z轴按客户划分泳道，可能不希望每个客户的泳道为了某个服务（如结账）而同步（阻塞）调用单一的支付网关。我们可以简单地实施N个支付网关，其中N是客户细分度或客户游道的数量。
如果有一些共享信息需要访问每个泳道，如登录凭据，应该怎么办？也许我们已经把认证和登录沿Y轴做了拆分，但我们需要在只读基础上从每个客户（Z轴）的泳道上取得相关的凭据。我们经常使用数据库的只读副本来满足这样的要求，把只读副本放在每个泳道中。许多数据库天然提供这种复制技术，甚至允许把数据切成小片，这意味着我们不需要在每个泳道中复制100%的客户数据。有些客户为了只读目的，把相关的信息缓存在相应泳道的分布式对象缓存中。
我们经常遇到的一个问题是如何在虚拟化服务器世界中实施泳道。虚拟化为故障隔离增加了新的维度——除了物理故障之外的逻辑（或虚拟）维度。如果实现虚拟化主要是为了把较大的机器分解成更小的机器，那么应该继续把物理服务器作为泳道的边界。换句话说，不要把来自于不同泳道的虚拟服务器放在同一物理设备上。然而，我们的一些客户常年有各种不同需求特性的产品，他们依靠虚拟化作为横跨所有产品的弹性容量。在这种情况下，我们试图限制混合在虚拟服务器上的泳道数量。理想情况下，把整个物理服务器用在一个游道上，而不是在该服务器上混合几个泳道。
