CAP猜想仅以它们最强的形式讨论一致性和可用性：可线性化和系统最终响应每一个请求的能力。

这迫使我们在这两个属性之间做出艰难的权衡。然而，有些应用程序可以从稍微放松的假设中获益，我们可以用它们较弱的形式来思考这些属性。

系统不一定非得在一致或可用中二选一，也可以提供更宽松的保证。我们可以定义两个可调试量：收成（harvest）和产量（yield），在两者之间进行选择仍然可以形成正确的行为。

收成：定义查询的完成程度。如果查询必须返回100行，但由于某些节点不可用而只能获取99行，这仍比查询完全失败而不返回任何内容要好。

产量：指成功完成的请求数与尝试请求总数之比。产量与正常运行时间（uptime）不同，例如一个繁忙的节点没有宕机，但仍然可能无法响应某些请求。

这就把权衡的重点从绝对条件变成了相对条件。我们可以用收成换取产量，并允许某些请求返回不完整的数据。例如，如果存储某些用户记录的节点子集宕机，我们仍然可以继续为其他用户处理请求。

定义和权衡收成与产量，并在二者之间做出慎重的决定，有助于我们建立容错性更好的系统。