What Makes a Great System Architect? Lessons from Alibaba’s Double‑11 Architecture

Understanding Technical Architecture

In large‑scale e‑commerce platforms, architecture must satisfy four primary goals: low cost, high efficiency, high stability, and rapid integration of new technologies. The design is divided into three layers.

Top‑Level Design

Similar to a national five‑year plan, the top‑level design defines clear objectives and measurable outcomes before any implementation begins. For a massive sales event such as Double 11, the architecture must explicitly state performance targets (e.g., QPS, latency), cost limits, and fault‑tolerance requirements.

Physical (Unit‑Based) Architecture

Alibaba’s unit‑based architecture isolates production traffic across geographically separated, independent data‑center units. Each unit runs a complete copy of the service stack, providing:

Isolation – failures in one unit do not affect others.

Independence – each unit can be upgraded or scaled without coordinated downtime.

Continuity – traffic can be rerouted across units to maintain service during regional outages.

Deploying units at “kilometer‑scale” distances ensures that a single network incident cannot cascade through the entire platform.

Application Architecture – “Star Ring”

The Star Ring middle‑platform abstracts pure code co‑construction into two orthogonal dimensions:

Horizontal business packages – groups of related services (e.g., membership, payment, inventory) that share common data models.

Vertical business packages – end‑to‑end functional slices (e.g., order processing) that span multiple horizontal layers.

This dual‑package model isolates business logic from other business units and from the underlying platform, eliminating tangled if‑else code paths that previously existed across more than 50 business units.

Architect Role

An architect must maintain a “scattered form but unified spirit” – the ability to think abstractly about whole classes of problems rather than isolated incidents. Core activities include:

Engaging with key stakeholders (e.g., event “captains”) to surface real‑world pain points.

Abstracting observed issues into reusable problem statements.

Designing solution patterns that address the abstracted class of problems.

Coordinating cross‑team implementation and ensuring the solution aligns with business goals.

Required Abilities of an Architect

Problem Discovery : Detect both manifest and latent issues, differentiate symptomatic fixes from root‑cause solutions, and recognize patterns that affect multiple services.

Problem Definition & Analysis : Articulate the essential elements of a problem, decompose it into short‑term (mitigation) and long‑term (architectural) solutions, and document the impact scope.

Problem Solving : Design implementation paths, produce concrete design artifacts (e.g., component diagrams, API contracts), and drive cross‑team execution while maintaining clear communication.

Effective communication is essential: architects must translate technical trade‑offs into business language and align upstream/downstream teams around a shared solution.

Challenges Faced by Architects

Global Perspective : View any feature (e.g., membership) within the entire ecosystem, understanding its upstream consumers and downstream dependencies.

Technical Breadth : Master a wide stack, including mobile/PC front‑ends, CDN, networking layers (TCP/IP, MAC), service discovery, routing, RPC frameworks (e.g., HSF), databases (strong synchronization, multi‑point writes), and messaging middleware.

Continuous Learning : Allocate 2–3 hours daily to systematic study of industry papers (OLTP, OLAP), emerging cloud services, and new hardware (e.g., domestic chips).

Business Understanding : Align architectural decisions with cost, efficiency, and user‑experience targets; treat architecture, technology, and business as a three‑way integration.

Result Orientation : Translate technical advances into measurable business value, avoid KPI‑driven silo decisions, and persist through coordination challenges such as cross‑team dependencies or hardware adoption hurdles.

Addressing these challenges requires a disciplined approach: abstract problems early, design reusable patterns, and continuously validate that the architecture delivers the intended business outcomes.