Unlocking Ultra‑High Availability: The Secrets of Geo‑Active Multi‑Active Architecture

System Availability

Understanding geo‑active multi‑active starts with the three core principles of good software architecture: high performance, high availability, and easy scalability.

High availability is measured by MTBF (Mean Time Between Failure) and MTTR (Mean Time To Repair) with the formula Availability = MTBF / (MTBF + MTTR) × 100% . Achieving multiple "9s" of availability requires minimizing downtime to seconds per day.

Single‑Machine Architecture

A simple start‑up system has a single application server and a single‑node database. Failure of the database (disk crash, OS error, accidental deletion) leads to total data loss.

Backup can mitigate loss but introduces two problems: recovery time (service is unavailable) and data staleness (backups are not real‑time).

Master‑Slave Replication

Deploy a second database instance as a replica that synchronously copies data from the master. Benefits include higher data integrity, fault tolerance (slave can be promoted), and read‑scale improvement.

Deploy multiple stateless application instances behind a load balancer (e.g., Nginx or LVS) to eliminate single‑point failures.

Risk of Uncontrolled Failures

Even with multiple servers, placing them in the same rack or cabinet creates risk: a switch or router failure can still bring down the service.

Distributing servers across different cabinets reduces risk but does not eliminate it because all cabinets share the same data center.

Same‑City Disaster Recovery (同城灾备)

To protect against data‑center‑level failures, build a second data center in the same city (B) connected to the primary (A) via a dedicated line.

Two backup models:

Cold backup : periodic data copy; B is idle until A fails.

Hot backup : real‑time replication; B can take over instantly.

Hot backup provides immediate failover but still requires DNS switch and service start‑up.

Same‑City Active‑Active (同城双活)

Both A and B data centers serve traffic simultaneously, improving availability and load distribution. However, B’s storage is a read‑only replica, so write traffic must still go to A.

To achieve true active‑active, both data centers must host writable primary databases and keep them synchronized.

Two‑City Three‑Center (两地三中心)

Deploy A and B in one city (active‑active) and a third data center C in another city for disaster backup (cold). This pattern is common in finance and government projects.

Pseudo Active‑Active (伪异地双活)

Simply extending same‑city active‑active to different cities introduces unacceptable latency (30‑100 ms) for cross‑city reads/writes, making the design ineffective.

Real Active‑Active (真正的异地双活)

Both data centers must have writable primary databases and synchronize data bidirectionally. This requires data‑sync middleware for MySQL, Redis, MongoDB, and message queues.

Conflict resolution strategies:

Automatic merge based on timestamps (requires tightly synchronized clocks).

Avoid conflicts by routing users so that all of a user’s requests stay within one data center.

Implementation Strategies

Three common routing/sharding rules:

Business‑type sharding: different services run in different data centers.

Hash‑based sharding: route users by hash of user ID.

Geographic sharding: route users based on physical location.

These ensure a user’s requests stay within a single data center, eliminating cross‑region latency and conflict.

From Active‑Active to Multi‑Active (异地多活)

Scale the active‑active design to more than two data centers. A star topology can be used where all sites sync to a central hub, simplifying data propagation.

The final architecture provides unlimited scalability, rapid failover, and high availability across regions.

Summary

1. Good architecture follows high performance, high availability, and easy scalability. 2. High availability hinges on rapid recovery; geo‑active multi‑active is a key technique. 3. Redundancy (backup, replication, disaster recovery, active‑active, multi‑center) is the core. 4. Hot backup enables instant failover; active‑active adds load sharing. 5. Two‑city three‑center adds disaster resilience at city level. 6. Real active‑active requires dual writable masters and bidirectional sync. 7. Multi‑active extends this to many regions, offering the strongest scalability and availability.