How Gaode Scaled Serverless to Handle 2 Million Calls per Minute During China’s Travel Festival

Background

During the 2020 "Golden Week" travel festival, Gaode Maps reached a record of over 100 million daily active users. The autonomous‑travel service, which handles the largest user traffic in the app, was migrated to a Serverless architecture. In the peak period the system processed close to two million function invocations per minute, demonstrating that Serverless can sustain extreme load.

Overall service success rate > 99.99 %, total triggers > 1 million per minute, QPS > 20 k, average response time < 60 ms across all scenarios.

Architecture Overview

The autonomous‑travel feature consists of three front‑end pages: the main map page, the route‑planning page, and the navigation‑completion page. Each page displays recommendation cards that must be updated quickly and styled flexibly. Gaode implemented the following Serverless pipeline:

UI template storage : Card templates (HTML/CSS) are stored in a cloud object store (e.g., OSS) and versioned.

Node FaaS layer : An Alibaba Cloud Function Compute (Node.js) function retrieves the template, aggregates data from downstream services, applies business logic, and assembles a JSON Schema that describes the final UI.

Client rendering : The mobile client receives the schema and renders the card locally, eliminating the need for a heavyweight BFF.

This design makes the front‑end layer stateless (Serverless For Front‑end, SFF), enabling automatic scaling to zero when idle.

Key Benefits

1. Simple Efficiency Gains

Traditional BFF layers become increasingly complex as features accumulate, leading to code bloat and maintenance bottlenecks. Replacing the BFF with SFF provides:

Zero‑maintenance functions that are created, updated, and deleted via code deployment.

Automatic scaling to zero, which instantly frees resources for unused endpoints.

A 40 % reduction in the end‑to‑end development lifecycle (development → testing → gray release → production) because the function code is small, isolated, and integrates directly with the CI/CD pipeline.

2. Elasticity and Cost Reduction

Map traffic exhibits sharp peaks and long troughs. With conventional servers, capacity must be provisioned for the peak, leaving large idle pools during off‑peak hours. Alibaba Cloud Function Compute offers millisecond‑level cold‑start and warm‑start times, allowing:

Instantaneous horizontal scaling based on request volume.

Pay‑as‑you‑go billing that charges only for actual invocations and execution time, dramatically lowering cost compared with always‑on VMs.

3. Observability

Function Compute integrates out‑of‑the‑box with Alibaba Cloud Log Service, CloudMonitor, distributed tracing, and Function Workflow. By configuring these services once, developers obtain:

Full‑stack metrics (QPS, latency, error rate).

Centralised logs for each function instance.

End‑to‑end request tracing across upstream services.

This unified observability simplifies troubleshooting and reduces the learning curve for operations teams.

Implementation Details

Key implementation steps are:

Store UI templates in OSS with a stable URL pattern.

Write a Node.js handler that:

const OSS = require('ali-oss');
const fetch = require('node-fetch');

exports.handler = async (event) => {
  // 1. Load template
  const template = await oss.get('templates/card.html');
  // 2. Call downstream data services
  const data = await fetch('https://api.gaode.com/rec', {method: 'POST', body: JSON.stringify(event)}).then(r=>r.json());
  // 3. Merge template and data into a schema
  const schema = buildSchema(template, data);
  return { statusCode: 200, body: JSON.stringify(schema) };
};

Deploy the function via Alibaba Cloud CLI or CI pipeline; set concurrency limits and timeout (e.g., 3 s) according to latency SLA.

Configure Log Service and CloudMonitor as the function’s log and metric destinations.

Caveats and Best Practices

Ensure the function remains stateless – do not store session data locally.

Set appropriate memory (128 MiB–512 MiB) to balance cold‑start latency and cost.

Use versioned OSS objects to avoid breaking clients when templates change.

Monitor cold‑start latency; if it exceeds the SLA, consider keeping a warm pool via provisioned concurrency.

Technical Illustrations