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.

Bộ đệm Sự kiện (Kafka)

Để bảo vệ core ledger và các databases, PayPay sử dụng rất nhiều Apache Kafka nhằm chuyển đổi từ xử lý đồng bộ sang xử lý bất đồng bộ.

Cách thức hoạt động:

  1. Phản hồi siêu tốc: Khi user thực hiện một action (vd: lấy coupon hoặc chuyển tiền P2P), edge service chỉ làm một khâu validate nhẹ.
  2. Publish vào Kafka: Event đó lập tức được đẩy vào một Kafka topic.
  3. Trả về cho User: API trả về trạng thái 202 Accepted hoặc Processing cho app của user chỉ trong vài mili-giây.
  4. Consume bất đồng bộ: Các worker chạy ngầm (consumers) sẽ kéo (pull) event từ Kafka ra để xử lý theo một tốc độ có kiểm soát — đúng với mức tải mà downstream databases có thể chịu đựng an toàn.

Hiệu ứng “Giảm xóc” (Shock Absorber)

Kafka đóng vai trò như một bộ giảm xóc khổng lồ. Kể cả khi 1 triệu user bấm “Thanh toán” vào cùng một giây, các request đó vẫn được xếp hàng an toàn trong Kafka. Backend phía sau vẫn tuần tự xử lý chúng mà không bị sập. User có thể thấy biểu tượng tải (loading spinner) quay lâu hơn khoảng 2 giây, nhưng quan trọng là giao dịch vẫn thành công.

Idempotency và Retries

Trong hệ thống event-driven, một message có thể bị đẩy xuống nhiều hơn một lần (cơ chế At-Least-Once delivery). PayPay bắt buộc phải áp dụng các Idempotency Keys thật chặt chẽ cho mọi giao dịch. Nếu Payment Service nhận cùng một Kafka message đến 2 lần, database phải nhận diện được cái Idempotency Key đó và bỏ qua request trùng lặp, ngăn chặn triệt để lỗi trừ tiền 2 lần.

Khi lượng giao dịch Kafka đổ về phía sau quá lớn, hệ quản trị cơ sở dữ liệu quan hệ truyền thống bắt đầu bộc lộ điểm yếu. Mời bạn đọc tiếp Phần 3 — Data Layer: Chuyển đổi từ Aurora sang TiDB.