Gần như mọi ứng dụng backend dùng Kafka đều gặp bài toán này: khi tạo một đơn hàng, bạn cần vừa ghi đơn vào database vừa gửi một sự kiện order_created lên Kafka để các dịch vụ khác (gửi email, tính kho, phân tích) phản ứng. Phản xạ đầu tiên là làm hai việc liên tiếp: INSERT vào DB, rồi gọi kafka.send(). Nhưng đây là một trong những cái bẫy phổ biến nhất của kiến trúc event-driven — vì DB và Kafka là hai hệ thống khác nhau, không có transaction chung. Giữa hai lời gọi luôn có một khe hở, và khi crash rơi đúng vào đó, hệ thống lệch nhau: DB có đơn mà Kafka không có sự kiện, hoặc ngược lại. Outbox pattern giải quyết triệt để. Bài này (phần 11/12) đo thật nó trong pg-lab.

Dual-write: vì sao ghi thẳng cả hai luôn có khe hở

"Dual write" là cách ngây thơ: ghi vào hai hệ thống trong hai thao tác tách rời.

tx.begin(); INSERT order; tx.commit();   // 1) ghi DB thành công
kafka.send(order_event);                 // 2) CRASH ở đây -> DB có order, Kafka KHÔNG có event

Vấn đề cốt lõi: không có transaction nào bao được cả hai. DB có transaction của nó, Kafka có cơ chế của nó, nhưng không có "distributed transaction" chung (và nếu có — two-phase commit — thì chậm và giòn). Nên luôn tồn tại một thời điểm mà một hệ thống đã ghi còn hệ thống kia chưa. Crash, mất mạng, hay restart rơi vào đúng khe đó là dữ liệu lệch — một sự kiện bị mất (consumer không bao giờ biết đơn được tạo) hoặc thừa (gửi sự kiện rồi DB rollback).

Ảnh chụp đoạn mã nền tối minh hoạ outbox pattern ghi database và gửi Kafka mà không bao giờ lệch nhau, ghi DB rồi gọi Kafka là hai thao tác tách rời crash ở giữa làm lệch outbox gom cả hai vào một transaction DB. Vì sao dual write hỏng ghi thẳng cả hai tx.begin INSERT order tx.commit 1 ghi DB thành công kafka.send order_event 2 CRASH ở đây DB có order Kafka không có event hoặc ngược lại gửi Kafka xong rồi commit DB fail Kafka có DB không hai hệ thống khác nhau không có transaction chung luôn có khe hở mất đồng bộ. Outbox ghi nghiệp vụ cộng sự kiện trong cùng một transaction DB BEGIN INSERT INTO orders VALUES 1001 thay đổi nghiệp vụ INSERT INTO outbox topic payload VALUES sự kiện cùng tx COMMIT nguyên tử hoặc cả hai vào hoặc không cái nào rollback. Relay tiến trình riêng đẩy outbox sang Kafka một relay đọc các dòng outbox chưa gửi produce sang Kafka đánh dấu sent SELECT FROM outbox WHERE NOT sent kafka.send UPDATE sent true relay chết giữa chừng dòng chưa đánh dấu sent sẽ được gửi lại at-least-once Debezium CDC đọc WAL thay cho relay thủ công là biến thể phổ biến

Hình 1: Dual-write ghi DB và Kafka tách rời — crash ở giữa làm hai hệ thống lệch nhau. Outbox gom thay đổi nghiệp vụ và sự kiện vào một transaction DB (nguyên tử), rồi một relay riêng đọc outbox đẩy sang Kafka.

Outbox: một transaction cho cả hai

Ý tưởng của outbox đơn giản mà tinh tế: đừng gọi Kafka trong luồng xử lý. Thay vào đó, ghi sự kiện vào một bảng outbox trong chính database, trong cùng transaction với thay đổi nghiệp vụ. Vì cả hai INSERT nằm trong một transaction DB, chúng nguyên tử: hoặc cả hai được commit, hoặc cả hai bị rollback. Không còn khe hở.

Rồi một tiến trình relay riêng đọc các dòng outbox chưa gửi, đẩy chúng sang Kafka, và đánh dấu đã gửi. Tôi dựng demo trong pg-lab với bảng orders (nghiệp vụ) và outbox (sự kiện):

BEGIN;
  INSERT INTO orders VALUES (1001, 'nguyen-van-a', 250000);        -- thay đổi nghiệp vụ
  INSERT INTO outbox (topic, payload) VALUES ('order-events', ...); -- sự kiện, cùng tx
COMMIT;   -- nguyên tử: cả hai vào, hoặc rollback thì không cái nào

Đo thật: tính nguyên tử và relay

Ảnh chụp bảng kết quả đo thật tính nguyên tử và relay outbox sang Kafka output thật pg-lab postgres 16 cộng kafka-lab bảng orders cộng outbox. Một nguyên tử commit thì cả hai vào rollback thì không cái nào COMMIT order 1001 orders cộng outbox cùng tx orders có outbox có, ROLLBACK order 1002 ghi cả hai rồi rollback orders không outbox không, sau cùng số dòng mỗi bảng orders bằng 3 outbox bằng 3 khớp nhau, order 1002 bị rollback không lọt vào bất kỳ bảng nào orders và outbox luôn đồng bộ vì chúng commit rollback cùng một transaction đây là điều dual-write không bao giờ đảm bảo được. Hai relay outbox chưa gửi message trong Kafka outbox chưa gửi trước relay 3 dòng message trong topic order-events sau relay order-events 0 3 ba message outbox còn chưa gửi sau relay 0, 3 dòng outbox đúng 3 message trong Kafka rồi đánh dấu sent true relay chết giữa chừng thì dòng chưa đánh dấu được gửi lại at-least-once consumer phải idempotent

Hình 2: Đo thật. Trên — commit order 1001: cả orders lẫn outbox đều có; rollback order 1002: không bảng nào có; cuối cùng orders=3, outbox=3 (khớp). Dưới — relay đẩy 3 dòng outbox chưa gửi thành đúng 3 message trong Kafka, outbox còn 0 chưa gửi.

Kết quả thật chứng minh từng tính chất:

  • Nguyên tử khi commit: COMMIT order 1001 → cả orders và outbox đều có dòng tương ứng.
  • Nguyên tử khi rollback: ghi order 1002 vào cả hai bảng rồi ROLLBACK → không bảng nào có order 1002. Đây là điểm mấu chốt: order 1002 không lọt vào bất kỳ bảng nào, nên không bao giờ có chuyện "DB có đơn mà sự kiện lệch". Cuối cùng orders=3, outbox=3 — luôn khớp.
  • Relay chuyển đúng số lượng: 3 dòng outbox chưa gửi → relay produce → đúng 3 message trong topic order-events (order-events:0:3), rồi UPDATE sent=true → outbox còn 0 chưa gửi.

So với dual-write: outbox đảm bảo orders và outbox đồng bộ (chúng commit/rollback cùng một transaction DB), còn việc đẩy sang Kafka tách thành một bước riêng có thể thử lại được. Nếu relay chết giữa chừng, dòng chưa kịp sent=true sẽ được gửi lại ở lần chạy sau — at-least-once (nối thẳng bài kafka-04/05), nên consumer phải idempotent. Nhưng không bao giờ mất sự kiện, vì nó đã nằm an toàn trong DB cùng với dữ liệu nghiệp vụ.

Đánh đổi cần cân nhắc

Relay thủ công vs CDC (Debezium). Demo này dùng relay kiểu polling — một tiến trình SELECT ... WHERE NOT sent định kỳ. Đơn giản nhưng có độ trễ (bằng chu kỳ poll) và tải truy vấn lên DB. Biến thể production phổ biến là Change Data Capture: Debezium đọc thẳng WAL (write-ahead log) của PostgreSQL, phát hiện dòng outbox mới gần như tức thời, đẩy sang Kafka — không poll, độ trễ thấp. Đổi lại phức tạp hơn (thêm Debezium connector, Kafka Connect). Chọn polling cho hệ nhỏ, CDC cho quy mô lớn.

Outbox tăng tải ghi và cần dọn. Mỗi thao tác nghiệp vụ giờ ghi thêm một dòng outbox — tăng tải ghi DB, và bảng outbox phình nếu không dọn. Cần một job xoá các dòng đã sent cũ (hoặc dùng DELETE ... RETURNING trong relay). Với throughput rất cao, bảng outbox tự nó thành điểm nghẽn — lúc đó CDC trực tiếp trên bảng nghiệp vụ (không cần bảng outbox) có thể hợp hơn.

Outbox cho at-least-once, không exactly-once. Outbox đảm bảo không mất sự kiện và DB-sự kiện đồng bộ, nhưng relay vẫn có thể gửi trùng (gửi xong, chết trước khi kịp đánh dấu sent). Đây là at-least-once — đúng như kỳ vọng trong hệ phân tán. Exactly-once end-to-end cần thêm consumer idempotent hoặc transaction Kafka. Outbox giải bài toán đồng bộ hai hệ thống, không xoá bỏ nhu cầu xử lý trùng ở phía consumer.

Ba ý mang về

  1. Dual-write luôn có khe hở mất đồng bộ. Ghi DB rồi gọi Kafka là hai thao tác trên hai hệ thống không có transaction chung — crash ở giữa làm DB và Kafka lệch nhau. Không có cách sắp xếp thứ tự nào xoá được khe hở này.
  2. Outbox gom nghiệp vụ + sự kiện vào một transaction DB. Đo thật: commit thì cả orders lẫn outbox đều có; rollback order 1002 thì không bảng nào có; cuối cùng orders=3 khớp outbox=3. Hai bảng luôn đồng bộ vì cùng commit/rollback.
  3. Relay đẩy outbox sang Kafka là bước riêng, thử lại được. Đo thật: 3 dòng outbox → đúng 3 message Kafka, rồi đánh dấu sent. Relay chết thì gửi lại (at-least-once → consumer idempotent). Production thường dùng Debezium/CDC thay polling để giảm độ trễ.

Nguồn

Phần sau là bài tổng kết sê-ri: khi nào nên dùng Kafka và khi nào không, so sánh với RabbitMQ và hàng đợi trên database, cùng một checklist vận hành đúc kết từ 11 bài đã đo.