High availability minimizes downtime using redundancy, health checks, failover, and multiple instances.
High availability means a service is designed to stay usable when an instance, machine, connection, or other component fails.
The goal is not to promise that nothing will ever go wrong. The goal is to reduce the chance and duration of an outage by keeping another healthy path ready, detecting trouble quickly, and moving work to that path.
Core idea: keep the service available even when part of the system is unavailable.
Think of a shop with several checkout lanes and a supervisor who closes a broken lane and directs customers to open lanes.
Customers keep using the same shop entrance. They do not need to know which lane handles the purchase. The supervisor needs a way to notice that a lane is unhealthy and a spare lane must already be ready to help.
If one instance fails its health check, the router stops sending new requests there and uses another healthy instance.
High availability reduces the blast radius of failures and shortens the time between failure and recovery.
Keep two or more instances, paths, or replicas so one failure does not remove the only way to serve users.
Test whether an instance is actually ready to receive work, not merely whether its process is running.
Move traffic or responsibility to a healthy replacement when the current component cannot serve reliably.
Detect, isolate, and recover from common failures without waiting for a human to repair the first component.
Use high-availability patterns where interruption would block an important user journey or business operation.
Run multiple application instances so one host or process failure does not take down the public API.
Keep ordering available during campaigns, while making sure payment and order state remain safe and consistent.
Protect login and session-related paths because an unavailable identity service can make the rest of a product feel unavailable.
Use replicas, automatic promotion, or multiple consumers when the data or work-processing layer also needs a recovery path.
An online retailer is running a one-day promotion. The product team wants shoppers to keep browsing and placing orders if one application machine fails.
Define the user journey that must remain available, the acceptable interruption, and the failure scenarios in scope. Track availability, failed requests, health-check time, failover time, duplicate orders, and recovery communication—not only the number of instances.
High availability is a system property: every critical dependency needs an appropriate recovery path, not just the web tier.
Creates another place for work to go, such as a second instance or database replica.
Health checks, metrics, and alerts identify whether the current path can still serve users.
Routing or ownership changes move work to the replacement path and record what happened.
A high-availability design must connect capacity, routing, state, detection, and recovery into one operating plan.
Keep a service usable when a component fails by using redundancy, detection, and failover.
Continue operating through a defined failure, often with little or no visible interruption. High availability may briefly interrupt service while it detects and fails over.
Restore service after a larger incident such as a regional outage, major data loss, or destructive event.
Handle more demand by changing capacity. More instances can help scale, but they do not automatically create failover.
Keep a recoverable copy of data. A backup helps restore data but does not serve live requests during an outage.
Distribute requests across targets. It supports high availability when it has health checks and healthy alternatives to route to.
Redundancy is necessary but not sufficient: without health checks, failover logic, and a protected data path, extra instances can still fail together.
| ENGLISH TERM | 中文 | SIMPLE ENGLISH | 中文小白理解 |
|---|---|---|---|
| High Availability | 高可用性 | Keeping a service usable for most of the time, even when parts fail. | 即使部分组件出问题，也尽量让服务继续可用。 |
| Redundancy | 冗余 | Having an extra component or path ready to help. | 多准备一个可以接替工作的部件或路径。 |
| Health Check | 健康检查 | A test that decides whether a target is ready to receive work. | 用来判断某个实例现在能不能接收请求的测试。 |
| Failover | 故障转移 | Moving work from a failed path to a healthy replacement. | 把工作从坏掉的路径转到健康的备用路径。 |
| Instance | 实例 | One running copy of an application or service. | 正在运行的一份应用或服务副本。 |
| Load Balancer | 负载均衡器 | A component that routes requests across service instances. | 把请求分配给多个服务实例的组件。 |
| Single Point of Failure | 单点故障 | One component whose failure can stop the service. | 一个部件坏了就可能让整个服务停止。 |
| Availability Zone | 可用区 | A separate infrastructure location designed to reduce shared failure. | 相对独立的一组基础设施，用来减少一起故障的风险。 |
| Replication | 复制 | Keeping synchronized copies of data or state. | 保存数据或状态的同步副本。 |
| Failover Time | 故障转移时间 | How long it takes to move service to a healthy path. | 服务切换到健康路径需要多长时间。 |
High availability minimizes downtime with redundancy, health checks, failover, and multiple instances.
For a PM, availability is a user journey and dependency question: decide what must stay usable, how much interruption is acceptable, and which failures are in scope.
Multiple instances are only one part of the design. The router, stateful dependencies, data replication, monitoring, and recovery process must also avoid a shared single point of failure.