One architecture has excellent performance and mediocre reliability; another is reliable at substantially higher cost. How should the trade-off be evaluated?

The evaluation

Convert reliability into money, and cost into a rate, then compare like with like.

1. Quantify the cost of unavailability, per unit time, for the specific system. For a booking platform: transactions per hour at peak times the conversion value, plus the customers who do not return, plus support cost, plus contractual exposure. This number is usually never computed and is the pivot of the entire decision.

2. Estimate the difference in expected unavailability between the architectures — not the marketing figure but a realistic estimate from the failure modes each has, informed by incident history rather than by theoretical availability arithmetic.

3. Multiply and compare against the cost difference. If the reliable architecture costs an extra amount per year and reduces expected downtime by an amount worth more than that, it pays. If not, it does not, and saying so is legitimate engineering.

Why this is harder than the arithmetic suggests

Availability is not uniformly valuable across time. An hour of downtime during peak booking season is worth many times an hour in a quiet period. The comparison should use the distribution of when downtime occurs, and reliability investments should be targeted at the periods that matter.

Reputational cost is real and hard to quantify. It is also frequently overstated in these conversations, and the honest approach is to state it as a range and note that the decision is not sensitive to it — or that it is, which is itself informative.

Complexity has a reliability cost. A "more reliable" architecture with more components, more failure modes and more operational surface may be less reliable in practice. Multi-region active-active is more available in theory and introduces bidirectional replication, conflict handling and split-brain risk. The comparison must use realistic operated reliability, not designed reliability.

The mechanism that makes it ongoing

An error budget. Rather than a one-time decision, set an availability target derived from business impact, measure against it, and let the budget govern the trade continuously — spend it on velocity when there is room, invest in reliability when there is not.

That converts a recurring argument into a measurement, and it makes the exception path explicit: an exhausted budget with a launch pending is a decision for whoever owns both reliability and revenue, recorded so a pattern of exceptions is visible. One exception is a business decision; a pattern means the target is wrong.

The judgement being tested

Whether you can resist both reflexes — "reliability at any cost", which over-invests in systems whose failure nobody notices, and "cost above all", which under-invests in the few whose failure stops revenue. The answer is per system, derived from impact, and stated as a number.