"High availability" too often appears as a line item that justifies a price. This page turns it into arithmetic and a list of design decisions — and once you run the numbers, you can see exactly where the money goes and what it buys back.

Availability is arithmetic

Note that each additional nine roughly doubles the cost rather than adding linearly. For most platform operators, 99.9% is the pragmatic sweet spot — the money for 99.99% is usually better spent elsewhere.

Remove single points before you scale

Prioritize by blast radius:

1. Database. Primary-replica replication with automatic failover is the floor. Target a switch inside 30 seconds — and only trust a failover path you have rehearsed. An unrehearsed automatic failover is more dangerous than a manual one.
2. Edge. Two load balancers with keepalived. A solved problem; copy the pattern.
3. Cache. If the cache dies, can the database absorb the load? If not, you need cache warm-up and circuit breaking, not just a restart.
4. Job queues. Consumption policy and priority ordering under backlog — deciding this in advance is a hundred times cheaper than firefighting it later.

Stateless: the precondition for scaling

Elastic scaling assumes stateless application servers — sessions off the box (into Redis, or token-based) and files off the box (into object storage). With those two in place, adding capacity is a number in a config. Without them, scaling is a migration project. The redesign typically takes two to three weeks, and its return is highest when completed before traffic grows, not after.

Scaling triggers: watch metrics, not the calendar

• CPU: sustained 5 minutes above 60% triggers review; 70% triggers scaling
• Latency: alert when P95 exceeds baseline by 50% — this catches problems earlier than CPU does
• Queue depth: steadily growing consumption lag is a leading indicator of capacity trouble
• Cadence: double first, then observe; 20% nudges are both slow and easy to misread

Degradation plans matter just as much: during a traffic spike, decide in advance what you protect (login, core browsing) and what you cut (reports, non-core features). Degradation decided on the spot cuts the wrong thing eight times out of ten.

How multilingual and multi-zone builds pull on architecture

Reporting, cache invalidation and scheduled jobs all feel time zones: jobs fire in UTC and display in the operator's zone, and cache expiry can no longer lean on a "3 a.m. lull" that does not exist across regions. These details are expanded in the multilingual practice.

One capacity-planning rule of thumb

Keep 40% headroom: when peak traffic arrives, headroom is your reaction time. Market attention to high availability rose noticeably in 2026 — the background is in the first-half review. How the architecture layer coordinates with interface-level retries and circuit breaking is covered in the API guide; key-management failover on the security side is in the security topic.

A textbook scaling failure

We once watched a cautionary tale play out: traffic tripled, operations added machines per the playbook, and the application layer scaled just fine — right up until the database connection pool blew. Every new machine arrived with its own connection ceiling, so more machines meant a harder-hit database. The scaling action itself caused the outage. The lesson: capacity planning must be end-to-end. Application, database, cache and queue are one system; a plan that sizes only one layer just relocates the pressure to the next. That case is why we now recommend capacity drills — simulating triple load in staging is dramatically cheaper than meeting triple load for the first time in production.