Kiến trúc hệ thống PayPay: Scale cho các chiến dịch khổng lồ

Bối cảnh PayPay ra mắt năm 2018 và nhanh chóng thống trị thị trường thanh toán di động Nhật Bản, một phần nhờ các chiến dịch marketing mạnh tay như chiến dịch “Tặng 10 Tỷ Yên”. Những chiến dịch này tạo ra các đợt tăng vọt traffic khổng lồ, không thể đoán trước, làm sập các hệ thống monolithic và đồng bộ truyền thống. Thách thức Hệ thống thanh toán đối mặt với một bài toán hóc búa trong giai đoạn tăng trưởng nóng: ...

Bounded Contexts & Microservices Khi PayPay ra mắt, kiến trúc cần phải đủ linh hoạt để lặp lại (iterate) nhanh chóng. Họ chọn Kiến trúc Microservices được host hoàn toàn trên AWS. Thay vì một monolithic to lớn, hệ thống được chia nhỏ thành các domain business logic riêng biệt (Bounded Contexts trong Domain-Driven Design): User Domain: Authentication, quản lý hồ sơ, eKYC. Wallet/Payment Domain: Quản lý sổ cái (Ledger), số dư (balances), xử lý giao dịch. Merchant Domain: Đăng ký đối tác, quản lý cửa hàng. Campaign/Promo Domain: Xử lý logic mã giảm giá, tặng điểm, hoàn tiền. Giao tiếp nội bộ: gRPC Để đảm bảo độ trễ (latency) thấp giữa 100+ microservices, PayPay chuẩn hóa sử dụng gRPC. Các contract protobuf khắt khe giúp đảm bảo backward compatibility và ranh giới API rõ ràng giữa các team, tránh được sự cồng kềnh và overhead của REST/JSON trong internal traffic. ...

Sự nguy hiểm của Xử lý Đồng bộ (Synchronous Processing) Trong một chiến dịch khổng lồ (ví dụ flash event hoàn tiền 50% đột ngột), chỉ số TPS (Transactions Per Second) có thể nhảy vọt 100 lần chỉ trong vài giây. Nếu kiến trúc hoàn toàn là đồng bộ: App của User -> API Gateway -> Payment Service -> Ledger Service -> Database Một đợt spike traffic sẽ lập tức làm cạn kiệt số lượng connection của database. Ledger Service sẽ bị timeout, dẫn đến lỗi dây chuyền (cascading failures) ngược trở lại API Gateway, và toàn bộ app sẽ sập. ...

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. ...

Thiết kế cho Sự cố (Designing for Failure) Ở quy mô của PayPay (100+ microservices, hàng ngàn pods, databases phân tán), chuyện phần cứng hỏng, đứt mạng (network partitions) hay pod crash không phải là trường hợp hiếm gặp (edge cases) — chúng xảy ra liên tục như cơm bữa. Kiến trúc hệ thống bắt buộc phải chấp nhận sự cố. Circuit Breakers & Fallbacks Nếu một downstream service (ví dụ service liên kết ngoài với Ngân hàng) bị sập, nó có thể gây ra lỗi dây chuyền. Các thread của calling service sẽ bị treo (hang) chờ đợi, dần dần ăn sạch memory và kéo sập luôn cả hệ thống app. ...

1. Tại sao các Chiến dịch Khuyến mãi là Bài Kiểm tra Áp lực Tối hạn Đối với hầu hết các hệ thống phần mềm, lưu lượng truy cập (traffic) tăng trưởng một cách dần dần — và các đội ngũ kỹ thuật có đủ thời gian để phản ứng. Nhưng đối với PayPay, sự tăng trưởng lưu lượng là tức thời và được lên lịch sẵn: ngay vào khoảnh khắc một chiến dịch cashback (hoàn tiền) trị giá hàng tỷ yên được kích hoạt vào đúng 12 giờ trưa thứ Sáu, hàng triệu người dùng Nhật Bản sẽ đồng thời mở ứng dụng, nhìn thấy banner quảng cáo và nhấn “Thanh toán”. ...

1. Tại sao một Nền tảng Thanh toán Quy mô lớn lại cần Kiến trúc AI Vào năm 2024, PayPay đã vượt qua cột mốc 70 triệu người dùng đăng ký. Ở quy mô đó, diện tích hỗ trợ (support surface) trở nên vô cùng khổng lồ: hàng triệu người dùng có các câu hỏi về thanh toán, tài khoản quá hạn, tranh chấp giao dịch và các tính năng sản phẩm. Diện tích phát hiện gian lận (fraud detection) cũng phình to theo từng người dùng mới và từng mẫu giao dịch mới. Đội ngũ kỹ thuật nội bộ — gồm hàng trăm kỹ sư thuộc nhiều đơn vị kinh doanh — tạo ra hàng nghìn quyết định mỗi tuần, vốn rất cần sự hỗ trợ của việc truy xuất và tổng hợp tri thức. ...