The reliability versus cost trade-off that keeps engineers awake

The reliability-cost tradeoff is the one that keeps engineers up at night

Because the cost of getting it wrong in one direction is financial. The cost of getting it wrong in the other direction is an outage

And outages are not abstract. They're 2am pages, angry customers, recovery stress, lost revenue, and sometimes lasting reputation damage

So when someone says "we can save $1,200 a month by removing the standby replica" the instinct is to resist. The replica hasn't saved us yet. But it might. And the day it does we'll be glad we paid for it

That instinct is not irrational. It becomes expensive when it applies to everything

Here's the question that cuts through it

What does a failure of this resource actually cost?

Not in the abstract. Specifically. If this instance fails, what breaks? For how long? What is the revenue impact per hour of downtime? What is the customer support cost? What is the engineering time to recover?

For a critical production database in a revenue-generating system: the cost of downtime is high and the cost of the standby replica is probably justified many times over

For a development environment database: what does a failure actually cost? A few hours of one developer's time. Is the standby replica saving you more than that per month? Almost certainly not

Reliability investment should scale with the business impact of failure

Infrastructure that the product's revenue depends on directly: invest in reliability

Infrastructure used by internal teams, test environments, low-traffic services: apply the cost constraint first and add reliability when the business case is clear

The mistake is applying the same reliability standard to everything

That's not engineering rigor. That's a refusal to make the decision

The decision is: what is this worth protecting and what would it cost us if it failed?

Make that calculation. Then design accordingly