Màn hình báo đã lưu đơn, nhưng bộ phận tiếp theo không nhận được thông báo. Nếu ứng dụng ghi cơ sở dữ liệu rồi gửi sự kiện như hai thao tác riêng, một lỗi ở giữa có thể làm hai hệ thống lệch nhau. Transactional outbox giải quyết ranh giới đó bằng cách ghi dấu sự kiện cùng giao dịch với dữ liệu nghiệp vụ.
Không coi gửi message là phần kéo dài tự nhiên của commit
Trong mô hình outbox, bảng nghiệp vụ và bản ghi sự kiện được ghi trong cùng transaction tại cơ sở dữ liệu phù hợp. Một bộ chuyển tiếp đọc sự kiện đã commit rồi gửi sang hàng chờ. Điều này khác với gửi thông báo ra ngoài trước khi biết transaction thành công. Nếu nghiệp vụ rollback, không được phát sự kiện như thể thay đổi đã tồn tại.
AWS nêu vấn đề dual write và lưu ý bộ chuyển tiếp có thể gửi trùng. Outbox không tự chứng minh tác động cuối chỉ xảy ra một lần. Consumer vẫn cần nhận diện sự kiện đã xử lý và thiết kế tác động nghiệp vụ phù hợp. Không lấy trạng thái “broker đã nhận” để kết luận hóa đơn, email hoặc kho hàng đã cập nhật.
Sổ đối chiếu ba trạng thái
| Mốc | Khóa cần giữ | Câu hỏi vận hành |
|---|---|---|
| Committed | Định danh nghiệp vụ + event_id | Thay đổi và outbox cùng tồn tại chưa? |
| Published | event_id + biên nhận broker | Đã giao cho tầng truyền chưa? |
| Applied | event_id + kết quả consumer | Tác động được xác nhận ở nơi nhận chưa? |
Ví dụ giả định: relay dừng sau khi gửi
Đơn M-17 và sự kiện E-17 đã commit. Relay gửi E-17 thành công nhưng dừng trước khi lưu trạng thái gửi. Khi khởi động lại, relay có thể phát E-17 lần nữa. Consumer phải dựa vào E-17 để nhận diện trùng, không chỉ nhìn thời điểm nhận. Nếu gửi email là tác động ngoài cơ sở dữ liệu, cần chốt thêm cách nhận diện và đối chiếu tác động đó; một bản ghi processed trong cơ sở dữ liệu không tự giải quyết mọi cửa sổ lỗi bên ngoài.
Bốn điểm lỗi đáng yêu cầu trình diễn
- Lỗi trước commit: cả dữ liệu nghiệp vụ và outbox không được để lại trạng thái hoàn tất giả.
- Commit xong, broker chưa nhận: sự kiện còn chờ, có thể tìm bằng event_id.
- Broker nhận, relay chưa lưu biên nhận: phát lại không được tạo tác động nghiệp vụ trùng.
- Consumer xử lý lỗi: phải phân biệt chưa áp dụng, đã áp dụng và chưa rõ kết quả.
Đây là kịch bản nghiệm thu đề xuất, không phải báo cáo các thử nghiệm đã chạy. Theo dõi độ tuổi bản ghi outbox và chênh lệch giữa committed với applied hữu ích hơn chỉ đếm số request HTTP thành công. Cần quy định ai được phát lại, giới hạn phạm vi và cách dừng khi dữ liệu nguồn đã thay đổi.
Khi nào chưa cần outbox?
Nếu hệ thống không có bước ghi sang hai nơi với yêu cầu nhất quán, thêm bảng outbox chỉ làm tăng việc vận hành. Hãy bắt đầu bằng sơ đồ các tác động cần giữ đúng. Với lỗi phát lại sau khi đã vào hàng chờ, tham khảo riêng cách phát lại dead-letter queue có kiểm soát; đó không thay thế bước ghi sự kiện cùng transaction.
Khi chuẩn bị tích hợp phần mềm doanh nghiệp, một đơn giả định cùng ba biên nhận commit, publish và applied sẽ giúp chốt tiêu chí hoàn thành cụ thể, trước khi lựa chọn nền tảng hàng chờ.
Nguồn tham khảo và giới hạn
AWS Prescriptive Guidance: transactional outbox pattern (đọc ngày 13/10/2026). Các biểu mẫu và tình huống trong bài là hướng dẫn biên tập hoặc ví dụ giả định; không phải kết quả kiểm thử, dữ liệu khách hàng hay cam kết năng lực đã triển khai. Cách áp dụng cần đối chiếu nền tảng và quyền thực tế.
