Cloud Native 4 min read

In‑Depth Look at Alibaba’s Same‑City Active‑Active Architecture

Alibaba’s same‑city active‑active architecture deploys multiple data centers within one city, splits traffic between them, and ensures instant failover with layered high‑availability across access, application, and data layers, using technologies like DNS, SLB, Nginx, Redis and OceanBase.

Mike Chen's Internet Architecture
Mike Chen's Internet Architecture
Mike Chen's Internet Architecture
In‑Depth Look at Alibaba’s Same‑City Active‑Active Architecture

Alibaba’s same‑city active‑active architecture is a core solution for large‑scale internet services that require high availability, high performance, and rapid recovery. It deploys two or more independent data centers within the same city, each capable of handling traffic.

In normal operation the two sites share traffic according to a configured ratio (e.g., 50 %/50 %). When one site fails, the other instantly takes over the traffic, ensuring continuous service.

The architecture consists of three key layers:

Access‑layer active‑active : User requests are routed through global traffic scheduling, DNS resolution and a smart load balancer (SLB or Nginx). The routing system can split traffic between the two sites and redirect it on failure.

Application‑layer active‑active : Services are designed to be stateless or minimally stateful, using external session storage, shared caches and service governance so that either site can process requests independently.

Data‑layer active‑active : The most complex part, handling data consistency. Alibaba typically uses different synchronization strategies (strong consistency, eventual consistency, or tiered tolerance) based on business needs, employing high‑reliability replication links and distributed consensus algorithms. The data layer often uses MySQL‑compatible OceanBase as the underlying database.

The following diagram (shown in the article) illustrates the flow from the client, through DNS/GSLB, the unified access layer (Nginx/SLB), the micro‑service layer (RPC/Web), the distributed cache (Redis) and finally the database layer (OceanBase), with arrows indicating cross‑data‑center replication.

<ol><li>[User client (App/Web)]</li><li>|</li><li>[DNS / Global Load Balancer (GSLB)]</li><li>50% flow / 50% flow</li><li>==================</li><li>【Same‑city A】【Same‑city B】</li><li>==================</li><li>[Unified Access Layer (Nginx/SLB)]</li><li>| |</li><li>[Microservice Application Layer (RPC/Web)] <--> [Microservice Application Layer (RPC/Web)] (cross‑data‑center RPC)</li><li>| |</li><li>[Distributed Cache (Redis)] [Distributed Cache (Redis)]</li><li>| |</li><li>[Database Layer (MySQL / Alibaba‑developed OceanBase)]</li><li>(Core: high‑reliability replication link / distributed consensus keeps sync)</li></ol>

By combining these layers, Alibaba achieves a layered high‑availability design where each tier provides dual‑active capability and routing, allowing seamless failover and maintaining business correctness.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

distributed systemsHigh AvailabilityNginxAlibaba CloudActive-ActiveSLBOceanBase
Mike Chen's Internet Architecture
Written by

Mike Chen's Internet Architecture

Over ten years of BAT architecture experience, shared generously!

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.