Alipay

Alipay Double 11: 544,000 TPS Architecture Explained Research Baseline Two different Double 11 peak figures circulate widely, and they measure different layers of the stack — conflating them is the most common error in write-ups on this topic: Figure What it actually measures Layer Source 544,000 TPS Alipay payment transactions per second (2019) Payment / ledger OceanBase engineering 61 million QPS Database queries per second at the same 2019 peak Database OceanBase engineering 583,000 orders/sec Order creation on Alibaba’s e-commerce platform (2020) Commerce / order intake Alibaba Group press release [!IMPORTANT] The widely-quoted 583,000 figure is order creation throughput on Alibaba’s commerce platform, not Alipay’s payment TPS. Alipay’s reported payment peak is 544,000 TPS. This article is about the payment-side architecture, so 544,000 TPS is the relevant number. ...

← Series hub ← Prev • Next → Answer-first: Alipay’s Logical Data Center (LDC) unitization architecture partitions database tables and application servers into self-contained “RZone” units based on user ID hashes. This multi-active setup bounds failure blast radiuses and allows horizontal scaling across multiple data centers. Prerequisite: Phase 1: Timeline and Scale Evolution This phase focuses on the architectural blueprint that enables planetary scaling while preserving absolute transactional correctness and operational control. The core design philosophy is: scale through containment, not coordination. ...

← Series hub ← Prev • Next → Answer-first: Surviving Double 11 requires production Full-Link Stress Testing (Shadow Database traffic simulation) and automated AI-driven operational playbooks to detect and isolate degraded nodes within 1 minute. Prerequisite: Phase 2: Core Architecture (LDC, Unitization, Multi-Active) This phase is about how peak performance becomes repeatable. The core claim of Alipay’s operations team is simple: peaks are won in preparation and automation, not heroics. Under planet-scale loads, manual operational tasks fail due to human latency. Therefore, readiness must be engineered into the software stack itself. ...

← Series hub ← Prev • Next → Answer-first: Alipay’s Double 11 engineering journey evolved over a decade from a centralized monolithic database (2009) to a planet-scale multi-active cloud-native architecture capable of processing over 544,000 TPS at peak. Prerequisite: Executive Summary Overview Answer-first: The Double 11 evolution tracks Alipay journey from monolithic database crashes in 2009 to multi-region active-active unitized architectures. Double 11 (Singles’ Day), initiated in 2009 as a minor promotional event on Taobao Mall, evolved over a decade into the world’s largest online shopping festival. For Alipay’s engineering teams, it served as an annual crucible: a predictable yet extreme spike in transaction volume that forced the continuous redesign of payment infrastructure. This timeline tracks the evolution of Alipay’s technical scaling from a centralized database model to a modern, elastic cloud-native architecture. ...

← Series hub ← Prev • Next → Answer-first: Alipay’s tech stack combines SOFAStack middleware, OceanBase distributed databases, and lightweight Service Mesh sidecars to achieve high-density microservice deployments with low inter-service RPC overhead. Prerequisite: Phase 3: Operations Playbook This phase describes the core technology layers and software engineering paradigms that Alipay developed to scale its transaction processing systems. Building systems for Double 11 is not only an infrastructure scaling challenge; it is a software complexity challenge. The engineering team had to design a unified core platform capable of handling thousands of distinct business requirements (promotions, installment plans, international cards) without turning the codebase into an unmaintainable monolith. ...

← Series hub ← Prev • Next → Answer-first: Alipay’s Double 11 technology deep dive reveals high-performance internals: binary Bolt RPC protocol multiplexing over single TCP streams, RocketMQ 2PC transactional messaging for async decoupling, OceanBase LSM-tree compaction tuning, and multi-zone Paxos quorum consensus to achieve 544,000 TPS payment processing. Prerequisite: Phase 4: Technology Overview This document is a deep-dive companion to Phase 4. It focuses on the internal mechanics that define the hard limits of peak performance systems: RPC protocol layouts, consensus log replication pipelines, storage engine compaction configurations, and distributed transactions. ...