How Alibaba’s Serverless FC Powers Double‑12 Traffic Peaks Without Ops

Business Requirement

During the Double‑12 promotion, the Tmall V‑ranking module needed a personalized product feed service built with functions. Requirements included delivering individualized feeds, handling traffic spikes without operational staff, and meeting security and observability standards.

Challenges

Data interconnect: functions run in the external FC environment cannot directly access internal services.

Scalability: the system must absorb massive traffic peaks without manual intervention.

Security: functions must pass pre‑release testing, support gray‑release, enforce permission controls, and be observable.

Solution Overview

Hybrid Cloud Connectivity

Alibaba’s hybrid‑cloud model connects the internal IDC with Alibaba Cloud via a dedicated hybrid‑cloud line, enabling traffic exchange between on‑premise and cloud resources.

Hybrid Cloud

Combines public and private clouds, offering high control, flexibility, reliability, and avoiding vendor lock‑in.

VPC

Virtual Private Cloud provides isolated private networks with configurable IP ranges, routing tables, and gateways, allowing cloud resources (ECS, RDS, LB) to run within the VPC.

Hybrid Cloud Dedicated Line

The dedicated line links the IDC and cloud VPC, enabling private, high‑speed traffic flow between them.

Cloud Backbone Network

Cross‑region traffic first returns to the IDC via the dedicated line, then traverses the backbone network to reach other regions.

Problem 1: Data Interconnect

Functions in the external FC environment need to call internal personalization and enrichment services, which are isolated by network segmentation. The hybrid‑cloud dedicated line resolves this by providing private connectivity.

Problem 2: Scaling Without Operations

Traffic during Double‑12 shows a 10× QPS variance. Traditional approaches (over‑provisioning or manual scaling) are inefficient. Serverless FC handles spikes automatically using two container types:

FC Container Types

Reserved containers: always running, similar to traditional servers, rotated every 5 hours.

Elastic containers: launched on demand when concurrency exceeds a configured threshold, and terminated when load drops.

Problem 3: Security and Governance

The platform provides application‑level isolation, permission control, gray‑release, and monitoring. Functions are grouped per business application in a single Git repo, and the platform automatically splits builds into independent function packages.

Solution Features

Business‑oriented development: each application’s functions share permissions and are versioned together.

Solution‑oriented approach: predefined solution templates (pure function, ICE full‑stack, RAX SSR) and customizable tenant‑specific solutions.

Gray Release

Function aliases enable traffic splitting between versions. The platform configures alias routing percentages for gradual rollout.

{
    "metadata": {
        "name": "fc-interaction-index2__stable",
        "description": ""
    },
    "apiVersion": "core/v1",
    "kind": "FuncAliasMeta",
    "spec": {
        "routing": {
          "2": 50
        },
        "functionVersion": "1",
        "functionName": "fc-interaction-index2",
        "functionGroupName": "fc-rank-v-ald"
    },
    "status": {
        "phase": "active"
    }
}

Automatic Domain Assignment

When a function with an HTTP trigger is deployed, the platform automatically assigns a unique sub‑domain under a pre‑registered wildcard domain, eliminating the need for manual domain procurement.

Summary

By leveraging hybrid‑cloud dedicated lines, FC’s reserved and elastic containers, multi‑level rate limiting, and the serverless development platform’s permission, gray‑release, and domain automation capabilities, Alibaba’s Tmall V‑ranking service successfully handled Double‑12 traffic peaks without operational staff, providing a reliable, secure, and scalable serverless solution.