🔗 API Testing · Chương 3 · Mục 3.3

Test đồng bộ dữ liệu giữa API, DB và message queue

🎯 Mục tiêu học: nhiều hệ thống xử lý bất đồng bộ qua message queue — API trả kết quả ngay, nhưng dữ liệu thực sự "ổn định" sau đó vài giây hoặc lâu hơn. Test kiểu này cần cách tiếp cận khác hẳn so với gọi xong assert ngay.

Ví dụ minh hoạ

POST /v1/orders  →  Response 201 ngay lập tức (status: PENDING)
                     →  đồng thời đẩy message "order.created" vào queue

Queue "order.created"  →  Email Service tiêu thụ message, gửi email xác nhận
                       →  Inventory Service tiêu thụ message, cập nhật tồn kho

Nếu Tester chỉ gọi API rồi lập tức kiểm tra email đã gửi/kho đã trừ, test sẽ FAIL giả (flaky) vì message có thể chưa được xử lý xong — đây không phải bug, mà là đặc thù bất đồng bộ cần test đúng cách.

Checklist test đồng bộ dữ liệu bất đồng bộ

Độ trễ xử lý bất đồng bộ

Mã TC	Nội dung	Kỳ vọng
TC-SYNC-01	Gọi API tạo đơn, sau đó chờ/poll (không assert ngay) tới khi tồn kho được cập nhật	API trả response nhanh (không chờ xử lý xong); dữ liệu cuối cùng đúng sau khoảng thời gian hợp lý

Message xử lý lỗi

Mã TC	Nội dung	Kỳ vọng
TC-SYNC-02	Email Service lỗi khi xử lý message 'order.created'	Đơn hàng vẫn giữ đúng trạng thái nghiệp vụ chính (PENDING/PAID) — lỗi ở service phụ (gửi email) không được làm hỏng luồng chính
TC-SYNC-03	Message rơi vào dead-letter queue sau nhiều lần retry thất bại	Có cơ chế giám sát/cảnh báo, không để message 'mất tích' âm thầm

Message bị xử lý trùng (at-least-once delivery)

Mã TC	Nội dung	Kỳ vọng
TC-SYNC-04	Message 'order.created' được deliver 2 lần cho cùng 1 order (hành vi phổ biến của nhiều message queue)	Không gửi 2 email, không trừ tồn kho 2 lần — consumer phải tự xử lý idempotency theo orderId

Thứ tự xử lý message

Mã TC	Nội dung	Kỳ vọng
TC-SYNC-05	2 message cập nhật trạng thái liên tiếp của cùng 1 đơn hàng (vd PAID rồi SHIPPED) tới không đúng thứ tự	Nếu nghiệp vụ yêu cầu thứ tự, hệ thống phải đảm bảo xử lý đúng tuần tự hoặc phát hiện được message tới sai thứ tự

📌 Ghi nhớ

Với hệ thống bất đồng bộ, luôn dùng chờ có điều kiện (poll/retry với timeout) thay vì assert ngay sau khi gọi API — nếu không, test tự tạo ra lỗi giả (flaky test) chứ không phản ánh bug thật.

📖 Thuật ngữ Anh–Việt (mục này)

Đề thi dùng thuật ngữ tiếng Anh — nhớ đúng cụm bên trái. Bấm 🔊 để nghe từng từ, hoặc "Đọc tất cả" để nghe lần lượt Anh → (vài giây) → Việt.

Thuật ngữ (EN)	Nghĩa & ghi nhớ nhanh
Message queue	Hàng đợi tin nhắn — cơ chế truyền dữ liệu bất đồng bộ giữa các service (vd Kafka, RabbitMQ)
Eventual consistency	Nhất quán cuối cùng — dữ liệu sẽ đúng sau một khoảng thời gian, không nhất thiết ngay lập tức
At-least-once delivery	Đảm bảo message được xử lý ít nhất 1 lần — nhưng có thể bị gửi trùng nhiều lần
Dead-letter queue	Hàng đợi chứa message xử lý thất bại nhiều lần, không đưa được vào luồng chính
Flaky test	Test không ổn định — lúc pass lúc fail dù code không đổi, thường do race condition/thời gian chờ sai

📎 Nội dung do maiqai.com biên soạn — luồng xử lý trong ví dụ chỉ mang tính minh hoạ, không thuộc hệ thống thật nào.