Zero Sum by Design: 10 Years of Uber's Payments Platform

Uber · 2026 (2016→2026) · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bối cảnh

• Gulfstream bắt đầu năm 2016 trong một phòng họp, với một nhóm nhỏ dựng bộ microservice nền; mười năm sau nhiều service đó vẫn chạy. Cùng thời gian, tổng giá trị đặt chỗ hằng năm của Uber từ 50 lên 217 tỉ USD; nền tảng vừa thu tiền khách vừa trả tiền cho tài xế, courier, merchant (tổng dòng tiền gần gấp đôi giá trị đặt chỗ) và giữ số dư sổ cái cho hơn 1,2 tỉ thực thể.

Thay đổi chính

• Money order bất biến: một chuỗi nợ/có giữa các thực thể của một giao dịch thật (chuyến, đơn Eats, lô hàng Freight, nạp Uber Cash). Ghi rồi thì không sửa; điều chỉnh (chuyến đổi giá, thiếu món) là money order mới, để hệ tự kiểm toán được.
• Tổng bằng không: kiểm trước khi commit rằng mọi dòng của một money order cộng lại bằng 0 (tiền không tự sinh hay mất), cộng nguyên tắc bút toán kép; theo năm tháng, nguyên tắc này được đẩy ngược lên các hệ thượng nguồn.
• Số dư nhất quán mạnh trên DynamoDB: 2016 Uber vừa rời monolith, MySQL shard tự làm không bảo đảm được nhất quán mạnh cho số dư, nên dựng kho này trên DynamoDB: mỗi thực thể (người chi, người nhận, doanh nghiệp) là một dòng chứa nhiều tài khoản con (khoảng 1 KB); phải dọn tài khoản con có số dư 0 để giữ kích thước dòng.
• Ba mô hình dữ liệu lõi vẫn dùng tới nay: money order, ledger (thực thể có một hay nhiều tài khoản), entity changelog (mọi thay đổi số dư, dựng lại được sổ cái từ đầu).
• Ghép lỏng: các microservice stateless, mỗi cái giữ một khúc vòng đời dòng tiền (tạo, xử lý, thu, trả), Kafka làm bus; hai nguồn sự thật chung là kho money order và kho số dư. Phần lớn dòng tiền đi qua pipeline bất đồng bộ này; luồng có người dùng đang chờ dùng workflow engine Cadence để thanh toán đồng bộ mà không phá trục bất đồng bộ.
• Không gắn với mảng kinh doanh: money order chung (thu, trả, hoàn tiền, commerce) là khái niệm của nền tảng; Freight, xe hai bánh, Transit, Hotels, thuê xe, Grocery, Ads, Memberships lên nền tảng mà lõi gần như không đổi.
• Không gắn với phương thức thanh toán: lõi chỉ biết một Payment Instrument chung với interface charge/disburse/refund; logic riêng của từng phương thức nằm trong hiện thực tích hợp. Thẻ, PayPal, Paytm, UPI, Alipay, Apple Pay, Google Pay, iDEAL, PIX, hàng chục ví địa phương, Uber Cash; riêng Uber Pay quản hơn 50 phương thức.
• Tiến hoá: yêu cầu kiểm toán sâu hơn dẫn tới LedgerStore (làm cùng team Storage, kho chống sửa đổi) thay DynamoDB cho order và changelog; Entity Fares ghi giá cho từng thực thể và thực thi tổng bằng không ngay lúc tính giá, vì hệ thượng nguồn không có cùng kỷ luật; thực thể nóng do B2B (Uber for Business, Uber Direct) giải bằng cơ chế ghi theo lô tuần tự, throughput gấp 10 (Uber 2026); Ledger-as-a-Service nhiều tenant cho Uber Cash, Uber Money, hoá đơn B2B, có cái chạy hơn 7 năm.

Vì sao

• Theo Uber, một nền tảng chuyển hàng trăm tỉ USD mỗi năm là kết quả của các quyết định nguyên tắc từ sớm được giữ suốt mười năm: bất biến cho audit trail sạch, tổng bằng không để tiền không sinh ra hay mất đi, nhất quán mạnh cho sổ cái tin được, và trừu tượng chung để nhận sản phẩm và phương thức mới mà không phải kiến trúc lại.

Bài học cho SWE

• Dữ liệu tiền nên chỉ-thêm: sửa là ghi bản điều chỉnh, không update.
• Bất biến kiểm được bằng máy (tổng bằng không) đặt ở điểm commit, và đẩy dần lên các hệ thượng nguồn.
• Đầu tư sớm vào mô hình dữ liệu lõi trả lãi lâu hơn mọi lựa chọn hạ tầng (kho đã đổi, mô hình thì không).
• Đặt khái niệm của nền tảng ở mức chung (money order, instrument) để mảng kinh doanh mới không chạm lõi.

Liên quan

• Giao dịch phân tán và nhất quán xuyên service · Chọn database theo workload
• Cùng công ty: Uber 2026 · Uber 2016
• Cùng bài toán: TigerBeetle 2024 (sổ cái bút toán kép)