Why should high availability not be a reflex?
High availability has a direct infrastructure cost, but above all a lasting cost in complexity, monitoring, operations, and testing. It only makes sense if the cost of an outage truly exceeds that extra cost.
The right question for an executive or a CTO is therefore not “how do we aim for maximum availability,” but “which level of downtime can the business accept, on which scope, and at what price.”
When is a standard architecture still enough?
A standard architecture often remains rational for a young product, an internal service, a limited-use tool, or an activity that can accept a planned downtime window and a recovery that is not instantaneous.
The topic changes when the service carries a client commitment, operational continuity, financial flow, field operations, or a cost of unavailability that far exceeds the cost of a more robust architecture.
Which criteria should guide the decision?
Useful criteria are the real criticality of the service, client commitments, acceptable downtime window, tolerated data loss, the single dependencies that still exist, and the team’s ability to operate a more complex architecture.
A multi-zone or multi-region architecture does not bring the expected resilience if the database, DNS, a third-party provider, one critical secret, or the failover procedure remain single points of failure.
Which deliverables support a serious decision?
Useful deliverables include a map of single points of failure, a comparison of possible scenarios, a failover hypothesis, the dependencies to address first, monitoring prerequisites, and an explicit target service level.
The best outcome is not always “go multi-region.” Sometimes it is confirming that a standard architecture remains sufficient as long as another part of the service is still the real risk.
