Idempotency

Phiên bản đa ngôn ngữ: Bài viết này có phiên bản tiếng Anh chuẩn quốc tế tại Part 2: Event-Driven Architecture — Kafka at Scale, Transactional Outbox & Idempotency (tanhdev.com). Bài trước: Phần 1 — Nền Tảng Microservices & Tự Động Hóa GitOps | Danh mục Series | Bài tiếp: Phần 3 — Tầng Dữ Liệu: Chuyển Dịch Từ Aurora Sang TiDB Multi-Raft Nguyên tắc cốt lõi (Answer-First): Việc đáp ứng các đợt tăng vọt lưu lượng thanh toán hàng ngàn TPS trong các đợt chiến dịch đòi hỏi phải tách rời hoàn toàn luồng tiếp nhận yêu cầu đồng bộ khỏi tiến trình ghi số dư xuống cơ sở dữ liệu. PayPay xây dựng Kiến Trúc Hướng Sự Kiện (Event-Driven Architecture) với hạt nhân Apache Kafka. Nhằm triệt tiêu rủi ro sai lệch tài chính giữa database và broker thông điệp, PayPay áp dụng mẫu thiết kế Transactional Outbox kết hợp Debezium CDC, xóa bỏ xung đột ghi kép (dual-write race conditions). Các worker tiêu thụ phía sau thực thi cơ chế Idempotency tuyệt đối nhờ khóa phân tán Redis và mã định danh UUIDv7, đi kèm hàng đợi lỗi Dead Letter Queue (DLQ) để các thông điệp dị dạng không bao giờ làm nghẽn tiến trình xử lý phân vùng. ...

📖 Bản tiếng Anh (English Edition) Điều hướng series: Đây là Phần 5 trong giáo trình Kiến Trúc Core Banking Phân Tán. ← Phần 4: Saga Pattern | Bài Tổng Quan Định Hướng | Phần 6: FAPI 2.0 Security → Phần 5: ISO 20022 pacs.008: Parse, Idempotency & Gateway Latency Answer-first: Chuẩn điện ISO 20022 thay thế định dạng cũ bằng cấu trúc XML/JSON giàu ngữ nghĩa cho thanh toán liên ngân hàng. Nhờ áp dụng bộ phân tích luồng zero-allocation trong Go kết hợp bộ lọc Bloom đa tầng, cổng thanh toán xử lý hơn 25,000 TPS với độ trễ tiếp nhận gói tin dưới 2 mili-giây. ...

← Chương trước: Phần 6: Khóa Phân Tán (Distributed Locks) & Xử Lý Đồng Thời | Mục lục Series | Chương tiếp theo: Phần 8: Saga Pattern & Giao Dịch Phân Tán Trong Go → Điều kiện tiên quyết: Bạn nên đọc Phần 6: Khóa Phân Tán (Distributed Locks) & Xử Lý Đồng Thời để nắm vững cơ chế loại trừ lẫn nhau phân tán, Fencing Tokens và các bất biến lưu trữ trước khi xây dựng kiến trúc khử trùng lặp API. ...

Phiên bản Tiếng Anh: 📖 Bản tiếng Anh (English Edition) Answer-first: Tính bất biến trong thanh toán đảm bảo gửi lại yêu cầu giao dịch không gây trừ tiền trùng lặp. Chuẩn thực chiến yêu cầu client gửi Idempotency-Key, băm SHA-256 dữ liệu để chống giả mạo request (HTTP 422), thuê khóa nguyên tử bằng Redis SET NX PX, và ràng buộc UNIQUE trong database làm chốt chặn cuối. Điều kiện tiên quyết: Bạn cần nắm vững các nguyên lý giao dịch phân tán, tính chất ACID trong cơ sở dữ liệu quan hệ, các lệnh nguyên tử trong Redis và hàm băm mật mã học trước khi bắt đầu chương này. ...

← Chương trước: Phần 8: Giai Đoạn 3 — Full Cutover Zero Downtime | Mục lục Series | Chương tiếp theo: Phần 10: 24 Quyết Định Kiến Trúc (ADRs) → Answer-first: Xử lý giao dịch phân tán khi khách hàng đặt hàng bằng cách kết hợp Transactional Outbox pattern trong PostgreSQL và Saga Choreography qua Dapr Pub/Sub, đảm bảo tính nhất quán cuối cùng giữa Giỏ hàng, Đơn hàng, Thanh toán và Kho vận. ...