Tổng kết case thanh toán: thiết kế hoàn chỉnh và các cái giá

TL;DR: Thiết kế thanh toán hoàn chỉnh xoay quanh một điểm không quay lại là lệnh trừ tiền. Phía trên nó, một transaction ngắn giữ hàng và ghi mã giao dịch rồi mới gọi nhà cung cấp, và hàng chỉ được nhả khi thanh toán đã thất bại chắc chắn. Phía dưới nó, IPN, tra cứu hai mốc và file đối soát cùng đổ vào một câu UPDATE một chiều, ghi bút toán trong cùng transaction vào sổ cái chỉ ghi thêm. Không lớp nào miễn phí. Bài này gom cái giá của từng lớp vào một bảng, kèm số đo bạn đã tự lấy.

Bạn bắt đầu từ 540 triệu đồng đang treo mỗi đợt sale mà hệ thống không biết. Sáu bài sau, khoản tiền đó đã có chỗ đứng trong một máy trạng thái, một lịch tra cứu và một câu FULL JOIN. Bài này không dạy thêm cơ chế nào. Việc của nó là ráp các mảnh lại, rồi để bạn kiểm xem mình nói được cái giá của từng mảnh hay chưa.

1. Ráp thành một thiết kế

Đi theo một lượt thanh toán, từ lúc khách bấm nút tới lúc tiền nằm trong sổ.

Khách bấm thanh toán. Server mở một transaction ngắn: chuyển chỗ giữ hàng từ held sang paying và ghi mã giao dịch vào bảng payments, COMMIT, rồi mới chuyển khách sang trang cổng hoặc gọi lệnh trừ một chạm (bài 03). Thứ tự đó có lý do: hết hàng là câu "không" duy nhất có thể xảy ra, nên nó phải được hỏi trước khi tiền đi. Lệnh trừ tiền chạy xong thì không đảo được nữa. Timeout thì thanh toán sang unknown, không sang failed, vì với giao dịch mập mờ thì đoán "thất bại" sai khoảng 60% số lần.

Từ đây chỉ còn việc chốt. IPN là đường chính, endpoint mỏng tới mức khó chết. Tra cứu hỏi ở phút 1 và phút 16, tốn 6 trong 10 lượt mỗi giây lúc đỉnh. File đối soát tới 6 giờ sáng hôm sau, và một câu FULL JOIN so sổ với file trước 12 giờ trưa (bài 05). Nguồn nào tới trước cũng đi qua cùng một câu UPDATE ... WHERE status IN ('pending', 'unknown'), và chính transaction đó ghi bốn bút toán vào sổ cái chỉ ghi thêm; người bán có thêm số dư dẫn xuất cập nhật cùng lúc (bài 04).

Phương án ngây thơ của bài 02 không có mặt trong hình. Nó không có ô nào cho chữ "chưa biết", nên mọi giao dịch mập mờ đã trừ đều thành một khoản lệch, và dashboard vẫn báo 0 đơn failed.

Mỗi mảnh của thiết kế đã có một hình ảnh đời thường ở bài của nó. Đặt cạnh nhau, chúng cho thấy mỗi mảnh giữ một điều khác nhau:

2. Bảng cái giá bạn đã chấp nhận

Cột "lựa chọn" chỉ đúng dưới ràng buộc chuẩn của case, không phải khuyến nghị chung.

Đọc cột cuối theo hàng ngang, mỗi cái giá đều có một con số đứng sau. Khi ai đó hỏi "sao không cập nhật số dư cho mọi tài khoản cho gọn", câu trả lời tốt là chỉ vào hàng thứ tư: khoảng 1.000 lượt mỗi giây so với đỉnh 3.000. Câu "vì nó phức tạp hơn" thì không thuyết phục được ai.

3. Ba câu SQL giữ cả thiết kế đúng

Phần lớn khoản lệch trong case đến từ vài dòng SQL viết thiếu một vế. Ba cặp dưới đây là những chỗ bạn đã đo được cái giá.

❌ Chốt trạng thái không kèm điều kiện trên trạng thái hiện tại.

UPDATE payments SET status = 'paid' WHERE id = :payment_id;

✅ Timeout tới muộn hay IPN trùng sẽ ghi đè trạng thái cuối. Thêm vế trạng thái thì tin tới sau chỉ trả 0 row:

UPDATE payments SET status = 'paid'
WHERE id = :payment_id AND status IN ('pending', 'unknown');

❌ Worker nhả mọi chỗ giữ quá hạn.

UPDATE holds SET status = 'released'
WHERE expires_at < now();

✅ Hạn 10 phút là của bạn, trang cổng mở 15 phút là của nhà cung cấp. Chỉ nhả chỗ chưa bắt đầu trả; chỗ paying về kho cùng transaction chốt thất bại:

UPDATE holds SET status = 'released'
WHERE status = 'held' AND expires_at < now();

❌ Lọc ngày ở WHERE sau FULL JOIN khi so sổ. Điều kiện ngày gặp NULL ở phía thiếu dòng, nên đúng hai kiểu lệch nguy hiểm nhất (file có mà sổ không có, sổ có mà file không có) bị loại; trên dữ liệu thử, câu so sổ trả 3 dòng thay vì 5.

✅ Lọc ngày trong subquery của từng phía, mốc viết kèm +07:

FROM (SELECT * FROM payments
      WHERE created_at >= '2026-10-18 00:00+07'
        AND created_at <  '2026-10-19 00:00+07') g
FULL JOIN (SELECT * FROM settlement_file
           WHERE settle_date = '2026-10-18') f
  ON f.txn_ref = g.txn_ref

4. Đổi ràng buộc, quyết định nào đổi?

Ba quyết định nằm trên ba trục riêng, nên một thay đổi ràng buộc thường chỉ lật một trục. Điểm nối là câu UPDATE một chiều: thứ tự bước tạo ra trạng thái unknown, ba nguồn chốt nó, và sổ ghi bút toán trong cùng transaction chốt. Đổi cách chốt mà bỏ vế điều kiện là kéo cả sổ lệch theo. Giờ tự thử với ba tình huống, rồi so với đáp án mẫu.

5. Đào sâu

Liên hệ các bài khác

• Bài 06: Đối chiếu thực tế cho thấy hệ thanh toán thật chọn khác bạn vì ràng buộc cụ thể của họ khác bảng của bạn, như API nhà cung cấp phát lại kết quả cũ hay chỉ chặn mã trùng, hay độ nóng của tài khoản. Bảng cái giá ở mục 2 là công cụ để làm phép so sánh đó.
• Bài 01 là nơi mọi con số trong bảng bắt đầu.

Tóm tắt

• Khi luồng có một bước không đảo được, hỏi từng bước khác "nó có thể từ chối vì nghiệp vụ không?" rồi xếp nó trên hoặc dưới bước đó.
• Khi nhiều nguồn cùng báo kết quả cho một giao dịch, cho chúng đi qua đúng một câu UPDATE có điều kiện trên trạng thái hiện tại.
• Việc cần làm sau bài này: đổi một dòng trong bảng ràng buộc, rồi xem trục nào lật và trục nào đứng yên.

✅ Self-assessment

• Ước lượng số lượt thanh toán mỗi giây lúc đỉnh, số giao dịch mập mờ, số tiền thực sự bị treo và số lượt ghi vào ba tài khoản chung từ bảng ràng buộc tự đặt, rồi so với trần ghi một hàng đo trên máy bạn
  • Nếu chưa: đọc lại bài 01, mục 4 về tiền treo và mục 6 tự đo trần bằng pgbench.
• Chẩn đoán các kiểu lệch tiền (khách đã trả mà đơn vẫn chưa thanh toán, khách bị trừ hai lần, đơn đã thanh toán mà sổ thiếu bút toán, hàng đã về kho trong khi khách vẫn trả thành công) khi luồng tin kết quả trả về đồng bộ gặp timeout, khách đóng trình duyệt hoặc tiến trình chết
  • Nếu chưa: đọc lại bài 02, mục 2 mô phỏng 100.000 lượt và mục 3 đến 5.
• Thiết kế thứ tự bước quanh lệnh trừ tiền không đảo được (giữ hàng rồi trừ tiền, trừ tiền rồi tạo đơn, hay giữ tiền rồi thu sau), kèm trạng thái chưa rõ và bước bù mà thứ tự đó đòi hỏi
  • Nếu chưa: đọc lại bài 03, mục 4 mổ từng cái giá và mục 5 máy trạng thái.
• Chọn cách ghi sổ cho từng nhóm tài khoản (cột số dư kèm bảng lịch sử, sổ cái bút toán kép chỉ ghi thêm lấy số dư bằng tổng, hay sổ cái kèm số dư dẫn xuất cập nhật cùng transaction) bằng cách so tranh chấp ghi trên tài khoản chung và độ trễ đọc số dư
  • Nếu chưa: đọc lại bài 04, mục 5 đến 7 và hình chọn theo từng tài khoản.
• Thiết kế cơ chế chốt và đối soát với nhà cung cấp (IPN, tra cứu định kỳ trong giới hạn API, so sổ với file đối soát) sao cho không giao dịch nào mập mờ quá 24 giờ và mọi khoản lệch lộ ra trước 12 giờ trưa hôm sau
  • Nếu chưa: đọc lại bài 05, mục 3 về ngân sách tra cứu và mục 5 so sổ trước 12 giờ trưa.
• Giải thích vì sao một hệ thanh toán thật chọn khác thiết kế của bạn dựa trên ràng buộc của họ
  • Nếu chưa: đọc lại bài 06, mục 2 cách đọc một case và bảng tổng hợp ở mục 6.

Bài tiếp theo

Case thanh toán là case cuối của tuyến Thiết kế Hệ thống, và tuyến khép lại ở đây. Muốn đào sâu nguyên lý đứng sau hai mảnh bạn vừa ráp, hãy ôn lại hai bài ở khoá tiên quyết: Khi nào tránh distributed transaction trong data-phan-tan cho saga và bước bù, và Event sourcing trong data-phai-sinh cho ý tưởng sổ chỉ ghi thêm rồi suy ra trạng thái.