Harvest and Yield
A refinement of CAP that treats availability as a continuum — yield is the fraction of requests answered, harvest is the fraction of data reflected in an answer.
Fox and Brewer's observation that "available" and "consistent" are not binary. A search index missing one of twenty shards can return results from nineteen: full yield (every request answered), reduced harvest (95% of the corpus consulted). Most users never notice.
This reframes the design conversation productively. Instead of "do we fail the request or serve stale data", you can ask which of the two to trade and by how much:
- Trade harvest, keep yield — search, recommendations, analytics, dashboards, feeds. Answer with what you have and say so.
- Trade yield, keep harvest — payments, inventory decrements, anything where a partial answer is a wrong answer. Refuse rather than mislead.
The architectural consequence is that a system should know which data is missing and be able to say so — an answer flagged "computed from 19 of 20 shards" is far more useful than either a silent partial result or a 500. That requires the aggregation layer to track completeness explicitly, which is a design decision to make early.