Building High Throughput Payment Account Processing

Uber · 2026 · 3. Quy mô lớn · Độ khó: Khó — bài gốc

Bối cảnh

• Gulfstream, nền tảng thanh toán lõi của Uber: kế toán bút toán kép, tuân thủ SOX, kiến trúc theo job/transaction, hàng triệu giao dịch mỗi ngày, audit trail bất biến bằng UAC (User Account Changelog).
• Hot account: đến 2023, một số tài khoản cần nhiều hơn giới hạn 3–4 cập nhật mỗi giây của hệ. Ví dụ: nhà vận hành marketplace lớn có hàng chục nghìn điều chỉnh mỗi ngày trên một tài khoản, mất 21–24 giờ mới xong; fleet operator tạo hàng trăm nghìn giao dịch mỗi ngày, quá một ngày mới xong, kèm các đợt bùng vào giờ cố định; khách Uber for Business trợ giá cho rider theo vùng.
• Mỗi thao tác gồm nhiều round-trip tuần tự: đọc tài khoản (30–70 ms), kiểm lịch sử xử lý (30–70 ms), cập nhật (60–160 ms), ghi audit (12–70 ms), tổng 130–370 ms. Mục tiêu trên 30 thao tác/giây/tài khoản là bất khả về toán học nếu làm tuần tự.

Thay đổi chính

• Gom lô để khấu hao round-trip, trong cửa sổ 250 ms (giới hạn mềm 1 giây cho thao tác real-time như giữ tiền thẻ). Đã loại: batch qua Kafka (trễ phía client và consumer 1–2 giây là bình thường), stream có thứ tự toàn cục (quá phức tạp, phải compaction thường), chia một tài khoản thành nhiều dòng DynamoDB (phá khái niệm một số dư, khó phát hiện tài khoản nóng), đặt service gần kho (chỉ được 2–3 lần, cần 10 lần).
• Ba service: Batch Creator nhận thao tác qua RPC, gom theo tài khoản vào lô có hạn thời gian bằng script Lua nguyên tử trên Redis, đẩy task vào hàng đợi Redis, trả kết quả cho client từ cache kết quả trên Redis. Batch Process: các processor ở nhiều zone tranh nhau nhận task, đọc tài khoản một lần, áp mọi thao tác trong bộ nhớ, ghi một lần bằng optimistic locking (tranh nhau nhưng chỉ một lần thành công); audit log tạm được lưu trước, ghi xong thì chuyển thành vĩnh viễn. Batch Post-Processing ghi UAC vào DB giao dịch và publish bất đồng bộ, ngoài đường găng.
• Kết quả: trên 30 thao tác/giây/tài khoản, latency hiệu dụng 8–20 ms mỗi thao tác trong lô, cả lô khoảng 400–650 ms; việc trước mất 21–24 giờ nay xong trong vài phút.
• Hai trở ngại khi phát triển: các máy không đồng ý về giờ nên instance Redis giữ lô là nguồn thời gian duy nhất cho ranh giới lô; audit log truyền thống làm bản ghi tài khoản vượt giới hạn kích thước khi cập nhật dày, nên làm định dạng MicroUAC dưới 100 byte vẫn đủ đảm bảo idempotency (phát hiện từ thử nghiệm production).
• Chịu lỗi: lỗi của từng thao tác được cô lập; Redis sập thì tạm không phục vụ nhưng không hỏng dữ liệu; audit dùng Redis cho tốc độ và Docstore cho độ bền; processor nhiều zone (tên zone làm ID executor) giảm hỏng lô khi một zone sập hay lúc deploy.
• Kiểm chứng: shadow traffic production sang hệ mới; kiểm đầy đủ (mọi audit log và giao dịch được ghi, mọi request được xử lý, mọi tác dụng phụ được sinh, không còn hold hay lock treo) và đúng (một Validation service so số dư và log của tài khoản A ở hệ cũ với B ở hệ mới, phải giống hệt); stress test bằng khuếch đại traffic shadow 10–15 lần để tìm throughput tối đa, latency dưới tải cực, nghẽn ẩn (pool kết nối DB, CPU).

Vì sao

• Phần lớn thời gian là round-trip tới kho, không phải tính toán; tài khoản nóng không chia được mà không phá ngữ nghĩa số dư, nên cách còn lại là giảm số round-trip trên mỗi thao tác.

Bài học cho SWE

• Khi khoá nóng không chia được, gom các thao tác trên nó vào một lần đọc và một lần ghi.
• Chọn cửa sổ gom theo ngân sách latency của thao tác nhạy nhất, không theo throughput tối đa.
• Đưa việc tuân thủ (audit) ra khỏi đường găng nhưng giữ trạng thái tạm để không mất.
• Ranh giới theo thời gian trong hệ phân tán cần một nguồn giờ duy nhất.
• Shadow + so trạng thái cuối giữa hai hệ là cổng cho hệ tiền; khuếch đại shadow để tìm trần.

Liên quan

• Batching và khấu hao round-trip · Hot partition và thundering herd · Giao dịch phân tán và nhất quán xuyên service
• Cùng công ty: Uber 2026
• Cùng bài toán: TigerBeetle 2024