← Chương trước: Phần 2 — Xử lý tải đột biến: Event-Driven & Kafka (2026) | Mục lục Series | Chương tiếp theo: Phần 4 — Vận hành: SRE & Chaos Engineering (2026) →

Answer-first: PayPay chuyển đổi tầng dữ liệu từ Amazon Aurora sang TiDB (Distributed SQL) để giải quyết giới hạn mở rộng ghi và loại bỏ nhu cầu sharding thủ công, đạt khả năng co giãn ngang với độ trễ thấp và tuân thủ chuẩn ACID.

Nút thắt cổ chai của Relational Database

Ban đầu, PayPay dựa vào AWS Aurora (MySQL) cho toàn bộ dữ liệu giao dịch cốt lõi (sổ cái, số dư user). Aurora là một database rất tuyệt, nhưng về bản chất nó vẫn là một RDBMS truyền thống. Bạn có thể dễ dàng scale read (bằng cách thêm Read Replicas), nhưng tất cả các thao tác Ghi (Writes) đều phải đi qua một Primary Node duy nhất.

Khi PayPay đạt tới mốc hàng chục triệu người dùng, lượng Write TPS trong các đợt chiến dịch đã bắt đầu chạm vào giới hạn vật lý của cấu hình Aurora lớn nhất (Giới hạn của Vertical Scaling).

Các giải pháp truyền thống (Và vì sao chúng thất bại)

  • Manual Sharding: Chia database dựa trên User ID (vd: Users 1-1M ở DB A, 1M-2M ở DB B). Cách này tạo ra một gánh nặng khổng lồ về mặt vận hành, logic định tuyến phức tạp trên application, và biến các giao dịch chéo shard (như User A chuyển tiền cho User B) thành thảm họa.
  • NoSQL (DynamoDB/Cassandra): Dù có thể scale horizontal thoải mái, nhưng các database NoSQL thường thiếu các chuẩn giao dịch ACID chặt chẽ và thiếu tính năng JOIN phức tạp — đây lại là các yêu cầu bắt buộc của một sổ cái tài chính.

Chuyển đổi sang TiDB (NewSQL)

Giải pháp của PayPay là áp dụng TiDB, một database phân tán mã nguồn mở (distributed SQL database) được build bởi PingCAP.

TiDB là gì?

TiDB mang lại cái tốt nhất của cả 2 thế giới:

  1. Khả năng Horizontal Scalability của NoSQL: Có thể thêm node thoải mái để scale ghi và lưu trữ ra vô tận.
  2. Chuẩn ACID của RDBMS: Hỗ trợ distributed transactions và có thể “giao tiếp” bằng giao thức của MySQL.

Cách PayPay sử dụng:

Bằng cách chuyển đổi các domain nặng về ghi (như Payment Ledger) sang TiDB, PayPay đã loại bỏ được cái nút thắt (bottleneck) ghi dữ liệu ở một node duy nhất.

  • Application vẫn viết các câu query SQL bình thường (y chang như đang nói chuyện với MySQL).
  • TiDB tự động, trơn tru phân tán dữ liệu và các câu query đó ngang qua một cluster các node lưu trữ trạng thái (TiKV).

Khi sắp có một chiến dịch khổng lồ, team Platform chỉ đơn giản là bổ sung thêm node TiDB vào để cân tải cho lượng Write, sau đó scale down lại khi chiến dịch kết thúc. Sự chuyển dịch này là một cột mốc quan trọng biến kiến trúc của PayPay trở thành thực sự có khả năng đạt chuẩn planet-scale.

Có một hệ thống tốt là chưa đủ, hệ thống đó cần phải đứng vững trước những sự cố đứt cáp, sập server không báo trước. Khám phá cách vận hành ở Phần 4 — Vận hành: SRE & Chaos Engineering.

🔗 Đọc thêm các chuyên đề liên quan:

← Chương trước: Phần 2 — Xử lý tải đột biến: Event-Driven & Kafka (2026) | Mục lục Series | Chương tiếp theo: Phần 4 — Vận hành: SRE & Chaos Engineering (2026) →

❓ Câu Hỏi Thường Gặp (FAQ)

Q1: Phần 3 — Data Layer: Chuyển đổi từ Aurora sang TiDB (2026) giải quyết vấn đề cốt lõi nào trong kiến trúc hệ thống?

Tại sao PayPay chuyển dữ liệu cốt lõi từ AWS Aurora sang TiDB (Distributed SQL)? Mở rộng horizontal mà không cần sharding ứng dụng thủ công (Cập nhật 2026).

Q2: Những lưu ý quan trọng nhất khi triển khai thực tế là gì?

Cần chú trọng phân tầng ranh giới trách nhiệm (bounded context), thiết lập cơ chế fallback dự phòng, và giám sát chặt chẽ qua metrics OpenTelemetry để phát hiện sớm các điểm nghẽn.

Q3: Làm sao để kiểm thử và đánh giá hiệu quả sau khi áp dụng?

Áp dụng kiểm thử tải (load test), benchmark độ trễ P95/P99 trước và sau triển khai, kết hợp tracing phân tán để xác minh tính ổn định dưới tải cao.