How Alibaba’s One‑Click Site Builder Powers Elastic Cloud Capacity for Double 11

Introduction

Every year the Double 11 shopping festival creates a global frenzy, with transaction peaks that are more than ten times the normal load. Traditional approaches require over‑provisioning of machines, leading to low utilization after the event. By exploiting cloud elasticity—deploying transaction units on a hybrid private‑public cloud and releasing them instantly after use—Alibaba can dramatically cut costs and improve service quality.

One‑Click Site Building

1.1 Background

One‑click site building rapidly deploys a transaction unit in an empty data center, providing immediate service capability. Its reverse process, one‑click de‑deployment, quickly cuts traffic and frees all physical resources. The approach builds on Alibaba’s multi‑active e‑commerce architecture and elevates operational efficiency.

First proposed in 2014, the process originally took about a month and required extensive manual involvement. Recent refactoring achieved a goal of building a unit within eight hours, supporting three cloud units with the fastest build time of six hours and minimal operator participation.

1.2 Challenges

The Double 11 architecture spans three regions and five units, introducing the first scenario of two units in the same data center. Controlling intra‑unit isolation, synchronizing units with the central hub, and maintaining visibility are major hurdles.

Building a unit requires a comprehensive knowledge base covering databases, middleware, unified access, and over a hundred applications (e.g., catalog, order, member). Detailed configuration, capacity, and dependency information must be maintained for each environment (production, pre‑release, test).

Implementation also demands precise step‑by‑step deployment procedures for each product, integrating new resources such as ECS servers, SLB load balancers, and Docker containers.

Finally, a technical system must orchestrate nearly four thousand deployment steps, ensuring safety, handling exceptions, and providing fallback strategies.

1.3 Technical Architecture

The platform abstracts atomic services, functional components, component orchestration, and workflow scheduling into four layers. The architecture diagram (see image) illustrates this hierarchy.

1.4 Atomic Services

Atomic services are the smallest callable units, wrapped by a service gateway that also handles logging, tracing, and alerting.

1.5 Functional Components

Related atomic services are aggregated into business‑level components (e.g., server creation, account addition, Docker upgrade). About 40 components are built from roughly 100 atomic services, each designed to be idempotent and reusable.

1.6 Component Orchestration

Components are dynamically arranged via a web UI to form executable workflows. Dependencies among middleware and applications are modeled as a directed acyclic graph, enabling a unified deployment flow.

1.7 Workflow Scheduling

The scheduler ensures high availability, fault tolerance, and concurrency control for distributed execution of thousands of sub‑processes.

Elastic Capacity Delivery

The latest elastic technology introduces an online machine‑learning algorithm that continuously measures performance changes, predicts capacity needs, and performs simple fault analysis, effectively flattening resource utilization across units.

Key questions addressed include predicting application cluster performance without human intervention, estimating required resources for a target transaction volume, determining optimal physical utilization for stability and cost, and budgeting resources.

By analyzing online web‑service traffic and resource usage, a scatter‑plot model is built to fit service capacity against CPU utilization. Extending the trend line yields an estimate of maximum service capability at a given utilization threshold.

In practice, multiple pressure levels are considered, and regression is used to account for performance degradation, allowing capacity planning that respects both resource limits and logical constraints.

These two “secret weapons”—one‑click site building and elastic capacity delivery—enable rapid pre‑event capacity preparation and immediate post‑event resource reclamation back to the cloud buffer for resale.