System Architecture

🇬🇧 Read the English version of this article on tanhdev.com Khi trào lưu Multi-Agent bùng nổ, phản xạ tự nhiên của hầu hết các Backend Engineer là: “Hãy đóng gói mỗi Agent thành một Microservice!”. Tư duy này cực kỳ hợp lý với các hệ thống Web/App truyền thống. Tuy nhiên, đối với hệ sinh thái AI Agents, kế thừa từ bài toán Agentic System Architecture, đây lại là khởi nguồn của thảm họa hiệu năng. ...

🇬🇧 Read the English version of this article on tanhdev.com Đồng Bộ Tồn Kho Thời Gian Thực Là Gì? Answer-first: Đồng bộ tồn kho thời gian thực (Real-time inventory synchronization) là quá trình lan truyền các thay đổi về số lượng hàng trong kho từ hệ thống gốc (database) tới tất cả các kênh bán hàng — web storefront, ứng dụng mobile, WMS, ERP — với độ trễ chưa tới một giây (sub-second). Thay vì phải phụ thuộc vào các tác vụ batch ETL chạy mỗi giờ, một pipeline CDC + Kafka sẽ stream mọi thay đổi tồn kho được commit thành một sự kiện (event), qua đó loại bỏ hoàn toàn tình trạng bán vượt mức (overselling) cũng như tránh hiển thị sai số lượng hàng hóa. ...

Executive Summary: Alipay Double 11 Architecture From 50M CNY to 544K TPS: Lessons in Building Planet-Scale Systems TL;DR (Too Long; Didn’t Read) Alipay đã tăng capacity 5,440 lần trong 10 năm (2009-2019), từ hệ thống gần như sập (phải cắt điện văn phòng, dùng đá lạnh để giải nhiệt) đến 544,000 giao dịch/giây với độ tin cậy 99.99%. 3 bài học chính: Thiết kế để chia nhỏ (Unitization) - không thể scale vertically vô hạn Kiểm thử sản xuất (Stress testing) - tự tin từ 60% lên 95% Tự động hóa mọi thứ - giảm 200 người xuống 10 người cho cùng công việc The Story: From Crisis to Record 2012: The Breaking Point Vấn đề: Khủng hoảng 3 đầu ...

Giai đoạn 4: Tổng quan Công nghệ 4.1 Kiến trúc Middle Platform (Nền tảng trung tâm - 中台架构) Lịch sử Phát triển (2015+) 2015: Alibaba công bố "Chiến lược Middle Platform" ↓ Đại Trung Đài, Tiểu Tiền Đài (Nền tảng giữa lớn + Tiền sảnh nhỏ) ↓ 2018: Toàn bộ hệ thống được chuyển lên cloud ↓ 2020: Nền tảng dữ liệu Cloud-native Khái niệm cốt lõi: “Đại Trung Đài, Tiểu Tiền Đài” ┌──────────────────────────────────────────────────────────────┐ │ Mô hình Middle Platform │ ├──────────────────────────────────────────────────────────────┤ │ │ │ ┌──────────────────────────────────────────────────────┐ │ │ │ TIỀN SẢNH (Nhỏ) │ │ │ │ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │ │ │ │ │Tmall│ │Taobao│ │Ele.me│ │Fliggy│ │... │ │ │ │ │ └─────┘ └─────┘ └─────┘ └─────┘ └─────┘ │ │ │ └──────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌──────────────────────────────────────────────────────┐ │ │ │ NỀN TẢNG TRUNG TÂM (Lớn) │ │ │ ├──────────────────┬──────────────────┬────────────────┤ │ │ │ │ │ │ │ │ │ Nền tảng │ Nền tảng │ Nền tảng │ │ │ │ Nghiệp vụ │ Dữ liệu │ Công nghệ │ │ │ │ │ │ │ │ │ │ • Trung tâm User │ • MaxCompute │ • Hạ tầng Cloud│ │ │ │ • Trung tâm SP │ • DataWorks │ • DevOps │ │ │ │ • Trung tâm Đơn │ • Analytics │ • Bảo mật │ │ │ │ • Thanh toán │ • AI/ML │ • Giám sát │ │ │ │ │ │ │ │ │ └──────────────────┴──────────────────┴────────────────┘ │ └──────────────────────────────────────────────────────────────┘ Nền tảng Dữ liệu Trung tâm (Thống nhất dữ liệu) Bốn Giai đoạn Phát triển Giai đoạn Thời kỳ Đặc điểm 1. Phân tán 2009-2012 Rời rạc, các ốc đảo dữ liệu 2. Vòng lặp đóng dọc 2012-2015 Các hệ thống dọc nhỏ lẻ 3. Middle Platform 2015-2018 Phương pháp luận thống nhất 4. Cloud-Native 2018+ Trên cloud, kiến trúc Lake House Các Công nghệ Cốt lõi MaxCompute: ...

Học Kiến Trúc Alipay Double 11 - Learning Index Nghiên cứu chi tiết về hệ thống xử lý 544,000 giao dịch/giây của Alipay 📚 Tài Liệu Học Tập 🚀 Bắt Đầu Nhanh # Tài Liệu Thời Gian Mục Tiêu 1 Executive Summary 15 phút Hiểu tổng quan và bài học chính 2 Index Tổng Hợp 10 phút Điều hướng đến tài liệu phù hợp 📖 Lộ Trình Học Chi Tiết Giai Đoạn 1: Nền Tảng Lịch Sử Phase 1: Timeline & Lịch Sử ...

So Sánh Alipay Stack với Công Nghệ Hiện Đại Tổng Quan So Sánh Alipay Stack Modern Equivalent Key Difference LDC + RZone Kubernetes + Multi-cluster LDC: Business-driven sharding; K8s: Infrastructure abstraction OceanBase CockroachDB/TiDB/YugabyteDB OceanBase: 10+ years prod, custom FPGA; Newer: Cloud-native first RocketMQ Apache Kafka/Apache Pulsar RocketMQ: LSM-tree + rich msg types; Kafka: Log-centric; Pulsar: Tiered storage SOFARPC gRPC/Envoy Proxy SOFARPC: Java-centric, financial features; gRPC: Cross-platform, protobuf SOFAMesh (MOSN) Istio/Linkerd MOSN: Go-based, X-protocol; Istio: Envoy C++, standard mesh CTU Modern ML Platforms CTU: Custom fraud-specific; Modern: General-purpose MLOps PouchContainer containerd/cri-o Pouch: Alibaba-specific; containerd: CNCF standard 1. LDC Architecture vs Kubernetes Multi-Cluster Kiến Trúc So Sánh ┌─────────────────────────────────────────────────────────────────────────────┐ │ LDC (Alipay) vs Kubernetes Multi-Cluster │ ├─────────────────────────────────────────────────────────────────────────────┤ │ │ │ LDC Architecture (Business-Driven) │ │ ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ │ │ RZone 1 RZone 2 RZone N │ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ │ │Users │ │Users │ │Users │ │ │ │ │ │1-1M │ │1M-2M │ │N-M │ │ │ │ │ ├─────────┤ ├─────────┤ ├─────────┤ │ │ │ │ │Apps │ │Apps │ │Apps │ │ │ │ │ │DB │ │DB │ │DB │ │ │ │ │ │Cache │ │Cache │ │Cache │ │ │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ │ │ │ │ │ │ • Sharding: User ID-based │ │ │ │ • Self-contained units │ │ │ │ • Cross-unit = Distributed txn │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────┘ │ │ │ │ Kubernetes Multi-Cluster (Infrastructure-Driven) │ │ ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ │ │ Cluster 1 Cluster 2 Cluster N │ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ │ │Region: │ │Region: │ │Region: │ │ │ │ │ │us-west │ │eu-west │ │ap-south │ │ │ │ │ ├─────────┤ ├─────────┤ ├─────────┤ │ │ │ │ │K8s Pods │ │K8s Pods │ │K8s Pods │ │ │ │ │ │Services │ │Services │ │Services │ │ │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ │ │ │ │ │ │ • Sharding: Infrastructure/region-based │ │ │ │ • Shared global services │ │ │ │ • Cross-cluster = Service mesh │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ Detailed Comparison Aspect LDC (Alipay) K8s Multi-Cluster Recommendation Sharding Strategy User ID / Business key Node/Region labels LDC approach cho data-intensive apps Unit Boundary App + Data + Cache Pods + Services LDC: true isolation; K8s: shared storage Cross-Unit Traffic Explicit ( costly ) Transparent via mesh LDC: intentional design; K8s: hide complexity Failover Manual/Scripted (RZone switch) Automatic (health checks) K8s wins cho automation Scaling Add RZone (complex) Add nodes (simple) K8s wins cho ops simplicity Data Consistency Strong (Paxos in unit) Eventual (cross-cluster) LDC wins cho financial data Khi Nào Dùng Cái Nào? Use LDC-style khi: ...

Phase 1: Timeline & Lịch Sử Double 11 - Alipay Scale Evolution Tổng Quan Sự kiện Double 11 (Singles’ Day) bắt đầu từ năm 2009 và đã trở thành sự kiện mua sắm trực tuyến lớn nhất thế giới, vượt xa Black Friday và Cyber Monday cộng lại. Timeline Chi Tiết 2009: Khởi đầu khiêm tốn Sự kiện: Taobao Mall (nay là Tmall) tổ chức chương trình khuyến mãi đầu tiên Quy mô: 27 thương hiệu tham gia Doanh thu: 50 triệu CNY (khoảng 7 triệu USD) Thách thức kỹ thuật: Giao dịch cao gấp 5 lần bình thường Hệ thống Alipay gần như chạm giới hạn tải Kỹ sư phải scale up thủ công khi thấy traffic tăng 2010: Chuẩn bị có chủ đích Alipay chủ động liên hệ Taobao Mall để hỏi về kế hoạch khuyến mãi Bắt đầu đưa Double 11 vào agenda cuộc họp ổn định hàng tuần Ước tính capacity: “Lấy giá trị ước tính rồi nhân 3” Li Junkui và team bắt đầu làm stress testing thủ công 2012: Khủng hoảng Scale - “Bước ngoặt sinh tử” Ba vấn đề nghiêm trọng đồng thời xảy ra: ...

Phase 2: Kiến Trúc Kỹ Thuật Sâu - Alipay Double 11 2.1 Logical Data Center (LDC) & Unitization Architecture Core Concept: “Unit” Định nghĩa: Unit là một tập hợp self-contained có thể hoàn thành toàn bộ business operations. Đây là phiên bản thu nhỏ của toàn bộ hệ thống: Có đầy đủ: Tất cả services và applications Không đầy đủ: Chỉ chứa một phần dữ liệu (data sharding) Ba Loại Zone trong LDC ┌─────────────────────────────────────────────────────────────┐ │ LDC Architecture │ ├─────────────────────────────────────────────────────────────┤ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ RZone 1 │ │ RZone 2 │ │ RZone N │ │ │ │ (Region) │ │ (Region) │ │ (Region) │ │ │ ├─────────────┤ ├─────────────┤ ├─────────────┤ │ │ │ • App Layer │ │ • App Layer │ │ • App Layer │ │ │ │ • Data Shard│ │ • Data Shard│ │ • Data Shard│ │ │ │ • Full Svcs │ │ • Full Svcs │ │ • Full Svcs │ │ │ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │ │ │ │ │ │ │ └─────────────────┼─────────────────┘ │ │ │ │ │ ┌──────────┴──────────┐ │ │ │ │ │ │ ┌──────┴──────┐ ┌──────┴──────┐ │ │ │ GZone │ │ CZone │ │ │ │ (Global) │ │ (City) │ │ │ ├─────────────┤ ├─────────────┤ │ │ │ • Config │ │ • User Info │ │ │ │ • CIF │ │ • Login │ │ │ │ • Shared │ │ • Frequent │ │ │ └─────────────┘ └─────────────┘ │ └─────────────────────────────────────────────────────────────┘ RZone (Region Zone) Tự chủ hoàn toàn: Có đủ data và services để xử lý business Data sharding: Mỗi RZone chỉ chứa một phần dữ liệu (ví dụ: user ID 1-1M ở RZone 1, 1M-2M ở RZone 2) Horizontal scaling: Thêm RZone = thêm capacity Multi-active: Nhiều RZone active đồng thời ở các region khác nhau GZone (Global Zone) Chỉ 1 instance toàn cục Chứa dữ liệu không thể chia nhỏ (inseparable): Config center CIF (Customer Information File) Shared global data Read/Write: Được tất cả RZones truy cập (tần suất thấp) CZone (City Zone) Giải quyết latency giữa các cities Chứa dữ liệu/services được RZone truy cập thường xuyên Mỗi business access ít nhất một lần Khác GZone: CZone được truy cập liên tục bởi RZone Lợi Ích LDC Architecture Vấn đề Giải pháp LDC Single point bottleneck Chia thành nhiều units Traffic allocation Request routing đến đúng RZone Data splitting Sharding theo unit Latency xuyên city CZone cache frequent data Remote disaster recovery Multi-active RZones Kết quả: ...

Phase 3: Quy Trình Vận Hành & Chuẩn Bị 3.1 Capacity Planning Peak Prediction Models Vấn đề: Double 11 có traffic peak gấp hàng chục lần bình thường, nhưng chỉ diễn ra trong thời gian ngắn. Giải pháp: Hybrid Strategy ┌──────────────────────────────────────────────────────────────┐ │ Capacity Planning Strategy │ ├──────────────────────────────────────────────────────────────┤ │ │ │ Daily Traffic Peak Traffic (Double 11) │ │ │ │ │ │ ▼ ▼ │ │ ┌───────┐ ┌───────────┐ │ │ │On-prem│ ──── Elastic ─────►│ On-prem │ │ │ │(Base) │ Scaling │ + Cloud │ │ │ └───────┘ └───────────┘ │ │ │ │ │ │ │ │ │ │ Normal Ops Peak Ops │ │ (Year-round) (1-2 months) │ │ │ │ Cost Optimization: Giữ resources 1 năm → Chỉ 1-2 tháng │ └──────────────────────────────────────────────────────────────┘ Resource Buffer Calculation: ...

Phase 4: Công Nghệ Chi Tiết - DEEP DIVE 📌 Nội dung bài viết (Mini-TOC): Middle Platform Architecture SOFAStack - Deep Technical Architecture RocketMQ - Message Queue at Scale OceanBase Storage Engine - Deep Dive CTU Risk Control - AI/ML Architecture Distributed Transaction Deep Dive Performance Numbers Summary Code Examples 4.1 Middle Platform Architecture (中台架构) - Chi Tiết Kỹ Thuật Data Middle Platform - Technical Implementation MaxCompute Architecture ┌─────────────────────────────────────────────────────────────────┐ │ MaxCompute Distributed System │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ Control Layer │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ • Job Scheduler • Resource Manager │ │ │ │ • Metadata Service • Security Manager │ │ │ │ • Query Optimizer • Data Catalog │ │ │ └──────────────────────┬──────────────────────────────────┘ │ │ │ │ │ Compute Layer │ │ │ ┌──────────────────────▼──────────────────────────────────┐ │ │ │ │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ │ │ Worker 1 │ │ Worker 2 │ │ Worker N │ │ │ │ │ │(10K svrs)│ │(10K svrs)│ │(100K svr)│ │ │ │ │ ├──────────┤ ├──────────┤ ├──────────┤ │ │ │ │ │ SQL Eng │ │ SQL Eng │ │ SQL Eng │ │ │ │ │ │ MR Eng │ │ MR Eng │ │ MR Eng │ │ │ │ │ │ Graph Eng│ │ Graph Eng│ │ Graph Eng│ │ │ │ │ └──────────┘ └──────────┘ └──────────┘ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ Storage Layer │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ Columnar Storage + Compression + Tiered Storage │ │ │ │ Hot (SSD) ──► Warm (SATA) ──► Cold (OSS) │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────┘ Scale: 100,000+ servers | 200,000+ daily users | 12 PB+ tables Key Technical Features: ...

Phase 5: Synthesis & Lessons Learned 5.1 Key Architectural Decisions Timeline 2008 ──────────────────────────────────────────────────────────► │ ├── Distributed Architecture │ └── Break monolithic → Scalable services │ 2013 ──────────────────────────────────────────────────────────► │ ├── LDC (Logical Data Center) │ └── Unitization → Horizontal scale │ └── Multi-Active └── Multi-region deployment → Disaster recovery │ 2014 ──────────────────────────────────────────────────────────► │ └── Automated Stress Testing └── Uncertain → Deterministic │ 2016 ──────────────────────────────────────────────────────────► │ └── Elastic Architecture └── Cloud integration → Cost optimization │ 2020 ──────────────────────────────────────────────────────────► │ └── Cloud-Native └── Kubernetes + Containers → Efficiency Detailed Decision Analysis Year Decision Context Impact 2008 Distributed Architecture Monolithic hit limits Foundation for future scaling 2013 LDC + Multi-active Oracle/power limits 20K TPS → Unlimited theoretical 2014 Automated Stress Testing 60% confidence 95% confidence, 100+ bugs caught 2015 Middle Platform Strategy Data silos Unified data, rapid innovation 2016 Elastic Architecture Resource waste 50% cost reduction 2018 Cloud Migration On-prem limits Global scale, 544K TPS 2020 Cloud-Native Efficiency Container-based auto-scaling 5.2 Patterns & Anti-patterns ✅ DO (Patterns That Worked) 1. Modularization / Unitization ✓ Chia hệ thống thành units độc lập ✓ Mỗi unit: self-contained, có đủ services + data ✓ Scale bằng cách thêm units (horizontal) Result: 20K → 544K+ TPS (27x growth) 2. Automation Everywhere ✓ Stress testing tự động (thay vì manual) ✓ Auto-scaling (thay vì human intervention) ✓ Monitoring & alerting (real-time) Result: 200 people → 10 people cho stress testing 3. Testing in Production ✓ Full-link stress testing trên production ✓ Shadow tables cho data isolation ✓ Real traffic patterns Result: Phát hiện 100+ critical issues trước event 4. Design for Failure ✓ Multi-active (một region down → traffic chuyển) ✓ Circuit breakers (fail fast) ✓ Degradation plans (graceful fallback) Result: 99.99% availability during peak 5. Strong Consistency for Financial Data ✓ Paxos protocol (consensus) ✓ 2PC cho distributed transactions ✓ RPO = 0 (zero data loss) Result: No financial data corruption at 544K TPS ❌ DON’T (Anti-patterns Avoided) 1. Vertical Scaling ✗ Mua server lớn hơn khi hit limits ✗ Oracle database không thể scale thêm Instead: Horizontal scaling với distributed architecture 2. Manual Processes ✗ Manual capacity planning ✗ Manual failover ✗ Manual intervention during peak Instead: Automated everything 3. Reactive Approach ✗ Chờ system crash rồi fix ✗ Không test trước production Instead: Proactive stress testing + monitoring 4. Single Point of Failure ✗ Một database chính ✗ Một data center ✗ Single coordinator trong 2PC Instead: Paxos replication + multi-active 5. Over-engineering Too Early ✗ LDC project: Start with Taobao Mall only (not all systems) ✗ MVP approach: Phase 1 trước, hoàn thiện sau Lesson: "Release even if only first phase is finished" - Cheng Li 5.3 Metrics & KPIs Evolution TPS (Transactions Per Second) 2009 ████ (~100) 2010 ████████ (~500) 2012 ████████████████ (~2,000) ← Limits hit 2013 ████████████████████████████ (20,000) ← LDC debut 2014 ██████████████████████████████ (50,000) 2019 ████████████████████████████████████████████████ (544,000) 0 100K 200K 300K 400K 500K Growth: 5,440x trong 10 năm ...

Plan Nghiên Cứu Full Flow Alipay Double 11 Architecture Tổng hợp kiến trúc kỹ thuật và quy trình vận hành của Alipay trong sự kiện 11/11, từ lịch sử 2009 đến hệ thống hiện đại xử lý 544K+ TPS. Phase 1: Tổng Quan & Lịch Sử (1-2 ngày) 1.1 Timeline Evolution Đọc “10 Years of Double 11” - Alibaba Cloud blog Tìm hiểu các mốc quan trọng: 2009: Sự kiện đầu tiên (50M CNY, 27 brands) 2012: Khủng hoảng scale - Oracle limits, power supply issues 2013: LDC Architecture debut - mục tiêu 20K TPS 2014: Stress testing system 2019: 544K TPS peak 2020+: Cloud-native, containerization 1.2 Bài Toán Thách Thức Scale: Hàng trăm triệu users Complexity: Mỗi giao dịch involve hàng trăm systems Financial stability: Mỗi giao dịch phải chính xác 100% Cost efficiency: Xử lý peak gấp hàng chục lần normal traffic Output: Timeline infographic + summary document ...