Multi-zone resilience for a payment service
A payment service runs on Alibaba Cloud in a single region. It uses an SLB, a set of ECS instances in one zone, and an ApsaraDB for RDS primary instance in the same zone. The business requires an RTO of 30 minutes and an RPO of near zero for the database, and the service must survive the loss of a single zone. The team has budget for redundancy but not for a full active-active deployment in two regions. Currently, a zone outage would take down both the app tier and the database. Backups are taken nightly.
1. Design a single-region, multi-zone architecture that meets the RTO/RPO requirements, and explain how each component contributes.
Read the worked answer
A single-region, multi-zone (multi-AZ) design can meet a 30-minute RTO and near-zero RPO without the cost of cross-region active-active.
Components:
- SLB across zones. Deploy the SLB so it distributes traffic to back ends in multiple zones; if one zone fails, traffic shifts to healthy back ends.
- ECS in at least two zones. Spread the app tier across zones (e.g., an Auto Scaling group spanning zones) so losing one zone leaves capacity in the other. Size each zone so the survivor can carry the load.
- RDS with a standby in another zone. Use RDS high-availability / multi-zone deployment, where a standby replica in a different zone takes over on failure. This gives near-zero RPO because changes are replicated to the standby, and failover is typically well within the 30-minute RTO.
- Health checks and failover tie it together: SLB removes failed back ends, and RDS promotes the standby automatically.
Each layer removes a single-zone single point of failure, which is exactly what the requirement demands.
2. The team also asks whether nightly backups are sufficient for the stated RPO. Evaluate this and state what else is needed.
Read the worked answer
Nightly backups alone are not sufficient for a near-zero RPO. A nightly backup means that in a disaster you could lose up to ~24 hours of transactions - an RPO measured in hours, not near zero.
What provides near-zero RPO:
- Synchronous or near-synchronous replication to a standby in another zone (the multi-zone HA deployment). The standby is continuously updated, so failover loses little or no data.
- Backups remain necessary but for a different purpose: they protect against logical errors, corruption, and accidental deletion, and support point-in-time recovery. Keep them, but do not rely on them to meet the RPO.
So the answer is layered: HA replication meets the RPO, while backups meet recovery-from-mistakes needs. Both belong in the design, and the team should test failover to confirm the real RTO.