At Least Once và Exactly Once: Phân biệt Delivery Guarantee và Effect Guarantee

At least once and exactly once mô tả hai lớp bảo đảm khác nhau: message có thể được giao nhiều lần, nhưng business effect của một logical event chỉ nên xảy ra một lần. Delivery guarantee, exactly-once effects và idempotency là 3 khái niệm cốt lõi của bài toán này. Chẳng hạn, một billing webhook có thể được retry sau timeout và grant cùng một entitlement hai lần nếu handler không nhận diện được event đã được xử lý. Đây là vấn đề mà kỹ sư backend thường gặp khi xây dựng hệ thống thanh toán, gói đăng ký, webhook hoặc hệ thống hướng sự kiện.

Bài viết này của OTTclouds sẽ giải thích sự khác nhau giữa delivery và effect, vì sao retries tạo duplicate, cách idempotency bảo vệ trạng thái nghiệp vụ và những giới hạn mà hệ thống vẫn phải chấp nhận.

Đây là bài tiếp nối chủ đề Transactional Outbox Pattern. Nếu Outbox giúp hệ thống hạn chế nguy cơ làm mất event, thì phần này tập trung vào cách xử lý event trùng lặp mà không tạo ra thêm business effect. Hai cơ chế bổ trợ cho nhau để xây dựng một hệ thống webhook đáng tin cậy hơn.

Giải thích at least once delivery và exactly once effects là gì?

At least once (ít nhất một lần) và exactly once (chính xác một lần) là hai nguyên lý truyền tải thông tin trong hệ thống phân tán (distributed system). At-least-once delivery có nghĩa là hệ thống có thể giao cùng một tin nhắn nhiều lần để giảm nguy cơ tin nhắn bị bỏ sót. Trong khi đó, exactly-once effects (hệ quả chính xác một lần)  là một logical operation chỉ tạo ra một kết quả trong phạm vi đã xác định.

Hai khái niệm trả lời hai câu hỏi khác nhau:

• Delivery guarantee: Message được người nhận nhìn thấy bao nhiêu lần?
• Effect guarantee: Việc charge, grant entitlement hoặc ghi ledger thực sự xảy ra bao nhiêu lần?

Điểm quan trọng là duplicate delivery không nhất thiết phải dẫn đến duplicate effect. Một event có thể đến ba lần, nhưng cả ba lần đều đi qua một handler idempotent và chỉ lần đầu tiên thay đổi trạng thái nghiệp vụ.

Delivery khác effect ở điểm nào?

Giả sử một khách hàng vừa nâng cấp gói đăng ký. Đơn vị cung cấp hóa đơn gửi event subscription.upgraded tới backend.

Backend cập nhật entitlement thành công, nhưng response trả về cho provider bị mất giữa đường. Provider không biết request đã được xử lý hay chưa, nên gửi lại cùng event.

Nếu handler chỉ thực hiện các hoạt động này, thì cùng một upgrade có thể được áp dụng nhiều lần.

receive event
grant premium entitlement
return success

Một handler an toàn hơn phải nhận diện logical event trước khi tạo effect:

receive event
identify stable event_id
atomically record event_id and update entitlement
return success

Ở đây, event có thể được delivery nhiều lần. Tuy nhiên, entitlement transition chỉ được commit một lần.

So sánh at-most-once, at-least-once và exactly-once

At-most-once ưu tiên tránh xử lý trùng, at-least-once ưu tiên không bỏ sót message, còn exactly-once hướng tới việc mỗi logical operation chỉ được xử lý hoặc tạo effect một lần trong phạm vi xác định. Ba cơ chế này khác nhau ở cách hệ thống đánh đổi giữa nguy cơ mất message, nhận message trùng và độ phức tạp khi đồng bộ trạng thái. Trong thực tế, nhiều hệ thống billing và webhook chọn at-least-once delivery kết hợp với idempotency để đạt exactly-once effects ở tầng nghiệp vụ.

Bảng so sánh chi tiết 3 cơ chế:

Trong thực tế, từ “exactly-once” luôn cần đi kèm câu hỏi: exactly once ở đâu, với effect nào và trong transaction boundary nào?

Vấn đề bắt đầu khi acknowledgement bị mất

Một sender thường gửi message rồi đợi acknowledgement (tín hiệu xác nhận), hay ack, từ receiver.

Failure khó xử lý nhất xảy ra theo luồng sau:

1. Sender gửi message.
2. Receiver nhận và xử lý message.
3. Receiver gửi ack.
4. Ack bị mất hoặc connection bị đóng.
5. Sender không biết receiver đã xử lý thành công hay chưa.

Sender chỉ còn hai lựa chọn:

• Retry: Có thể tạo duplicate nếu receiver đã xử lý message.
• Không retry: Có thể mất operation nếu receiver chưa từng nhận message.

Đây không phải là lỗi riêng của bên cung cấp webhook, mà là tình huống thường gặp khi hai hệ thống trao đổi dữ liệu qua mạng. Chẳng hạn, Stripe sẽ tự động gửi lại những webhook chưa nhận được xác nhận và khuyến nghị hệ thống tích hợp kiểm tra xem event đã được xử lý hay chưa trước khi thực hiện lại logic nghiệp vụ. Vì vậy, mục tiêu thiết kế thực tế không phải là loại bỏ hoàn toàn các message trùng lặp trên đường truyền, mà là bảo đảm chúng không tạo ra thêm tác động ngoài ý muốn.

Vì sao exactly-once delivery chỉ đúng trong phạm vi giới hạn?

Exactly-once delivery, hay bảo đảm một thông điệp chỉ được giao đúng một lần, chỉ có thể áp dụng trong phạm vi mà nền tảng kiểm soát được toàn bộ quá trình gửi, nhận, lưu trạng thái và xác nhận kết quả. Khi một event được gửi qua mạng tới hệ thống bên ngoài, bên nhận có thể đã xử lý thành công, nhưng tín hiệu xác nhận lại bị mất trên đường quay về. Lúc này, bên gửi không thể biết chắc lần gửi trước đã thành công hay chưa. Nếu gửi lại, hệ thống có thể tạo ra một bản trùng; nếu dừng lại, thông điệp có thể bị bỏ sót.

Vì vậy, bảo đảm exactly-once của message broker hoặc nền tảng xử lý luồng dữ liệu thường chỉ đúng trong phạm vi nội bộ mà chúng kiểm soát. Một số nền tảng có thể cung cấp exactly-once semantics, tức là cơ chế xử lý chính xác một lần, nhưng bảo đảm này luôn đi kèm với một phạm vi cụ thể.

Chẳng hạn, Kafka Streams có thể phối hợp vị trí đọc của consumer, nơi lưu trạng thái và giao dịch của producer để mỗi event chỉ được xử lý một lần trong luồng Kafka. Apache Flink cũng có thể khôi phục trạng thái từ checkpoint, tức là điểm lưu trạng thái định kỳ, để quá trình xử lý sau sự cố tiếp tục gần giống như khi lỗi chưa từng xảy ra.

Tuy nhiên, bảo đảm đó không tự động mở rộng sang các hệ thống bên ngoài như API HTTP, dịch vụ email hoặc một cơ sở dữ liệu không tham gia cùng cơ chế giao dịch. Flink cũng nêu rõ rằng chế độ exactly-once đối với trạng thái nội bộ không mặc định bảo đảm các thao tác với hệ thống bên ngoài chỉ xảy ra một lần.

Ví dụ:

Kafka transaction commits
        ↓
consumer calls external HTTP API
        ↓
external API succeeds
        ↓
consumer crashes before saving local completion state

Khi consumer khởi động lại, nó có thể gọi API thêm một lần nữa vì trong hệ thống chưa có trạng thái xác nhận rằng lần gọi trước đã hoàn tất. Kafka cũng không thể hoàn tác tác động đã xảy ra trong hệ thống bên ngoài.

Do đó, không nên hiểu exactly-once delivery là một bảo đảm áp dụng cho toàn bộ quy trình từ đầu đến cuối. Khi luồng xử lý đi ra ngoài phạm vi giao dịch do nền tảng kiểm soát, hệ thống vẫn cần idempotency và cơ chế chống xử lý trùng ở phía nhận.

Idempotency tạo exactly-once effects như thế nào?

Idempotency giúp một thao tác nghiệp vụ, dù được gửi hoặc xử lý lại nhiều lần, vẫn chỉ tạo ra một kết quả duy nhất. Để làm được điều này, hệ thống gắn cho mỗi event hoặc request một mã nhận diện ổn định, gọi là idempotency key. Mỗi lần nhận message, service sử dụng key này để xác định đây là một thao tác mới hay là lần gửi lại của thao tác đã được xử lý trước đó.

Một quy trình an toàn thường diễn ra như sau:

1. Nhận event và lấy idempotency key.
2. Ghi key vào nơi lưu trữ bền vững.
3. Dùng ràng buộc duy nhất, hay unique constraint, để chỉ ra một worker có thể tiếp nhận key đó.
4. Cập nhật trạng thái nghiệp vụ trong cùng một database transaction.
5. Nếu key đã tồn tại, bỏ qua phần xử lý nghiệp vụ hoặc trả lại kết quả đã lưu trước đó.

Điểm quan trọng nhất là việc ghi nhận idempotency key và cập nhật trạng thái nghiệp vụ phải được thực hiện trong cùng một thao tác có tính nguyên tử. Nói cách khác, hai thay đổi này phải cùng thành công hoặc cùng thất bại. Nếu chúng được thực hiện riêng biệt, hệ thống vẫn có thể tạo ra kết quả trùng lặp khi nhiều worker xử lý cùng một event tại cùng thời điểm.

Chỉ có idempotency key vẫn chưa đủ

Đoạn mã sau thoạt nhìn có vẻ hợp lý, nhưng vẫn tồn tại race condition, tức tình trạng nhiều tiến trình cùng truy cập và thay đổi dữ liệu theo thứ tự không thể kiểm soát:

if event_id not in processed_events:
    grant_entitlement()
    insert processed_events(event_id)

Vấn đề xảy ra khi hai worker cùng kiểm tra dữ liệu trước khi một trong hai kịp ghi event_id vào bảng:

Worker A: event chưa tồn tại
Worker B: event chưa tồn tại
Worker A: cấp entitlement
Worker B: cấp entitlement

Cả hai worker đều cho rằng đây là event mới và cùng thực hiện việc cấp quyền. Kết quả là một event tạo ra hai tác động nghiệp vụ, dù hệ thống đã có bước kiểm tra idempotency key.

Để tránh tình trạng này, việc giành quyền xử lý event và tạo ra kết quả nghiệp vụ phải được phối hợp trong cùng một thao tác nguyên tử. Khi bản ghi chống trùng và trạng thái nghiệp vụ cùng nằm trong một database, có thể đặt chúng trong cùng một transaction:

BEGIN;

INSERT INTO processed_events (
    event_id,
    event_type,
    payload_hash,
    status
)
VALUES (
    :event_id,
    :event_type,
    :payload_hash,
    'processing'
)
ON CONFLICT (event_id) DO NOTHING;
-- Nếu không tạo được dòng mới, event này đã tồn tại.
-- Kiểm tra payload nếu cần rồi dừng xử lý.

UPDATE subscriptions
SET plan = :new_plan,
    updated_at = NOW()
WHERE subscription_id = :subscription_id;

UPDATE processed_events
SET status = 'completed',
    completed_at = NOW()
WHERE event_id = :event_id;

COMMIT;

Trong cấu trúc này, unique constraint trên event_id giúp database bảo đảm chỉ một worker có thể tạo bản ghi cho event. Transaction tiếp tục bảo đảm rằng bản ghi chống trùng và thay đổi subscription không bị lệch nhau: hoặc cả hai được lưu thành công, hoặc toàn bộ thay đổi được hoàn tác.

Tuy nhiên, hệ thống không nên chỉ kiểm tra key mà bỏ qua nội dung request. Nếu cùng một idempotency key được gửi lại với payload khác, đây có thể không phải là một lần retry hợp lệ mà là lỗi sử dụng key. Hệ thống có thể lưu thêm payload_hash, tức là giá trị đại diện cho nội dung payload, hoặc các trường bất biến của thao tác để phát hiện trường hợp cùng key nhưng khác dữ liệu.

Vì vậy, idempotency key không tự động tạo ra exactly-once effects. Bảo đảm này chỉ hình thành khi key được lưu bền vững, có cơ chế ngăn xử lý đồng thời, được liên kết nguyên tử với thay đổi trạng thái nghiệp vụ và được kiểm tra để tránh tái sử dụng sai mục đích.

Transactional Outbox giải quyết gì và không giải quyết gì?

Transactional Outbox giúp tránh tình trạng dữ liệu nghiệp vụ đã được cập nhật nhưng event tương ứng không được ghi nhận để gửi đi. Tuy nhiên, pattern này không loại bỏ event trùng lặp và cũng không bảo đảm exactly-once effects cho toàn bộ hệ thống phía sau.

Vấn đề mà Transactional Outbox xử lý thường được gọi là dual-write, tức là service phải thực hiện hai thao tác ghi độc lập:

Cập nhật dữ liệu trong database
        ↓
Publish event lên message broker

Nếu hai thao tác này không nằm trong cùng một transaction, sự cố có thể xảy ra ở khoảng giữa. Ví dụ, service đã cập nhật database thành công nhưng gặp lỗi trước khi publish event. Khi đó, trạng thái nội bộ đã thay đổi, nhưng các service phía sau không nhận được thông báo để cập nhật theo.

Transactional Outbox thay đổi quy trình bằng cách ghi cả dữ liệu nghiệp vụ và event chờ gửi trong cùng một database transaction:

BEGIN
update business state
insert outbox event
COMMIT

Vì hai thay đổi được thực hiện trong cùng transaction, chúng sẽ cùng thành công hoặc cùng thất bại. Sau khi transaction hoàn tất, một tiến trình riêng gọi là relay sẽ đọc event từ bảng outbox và publish lên message broker. Nhờ đó, hệ thống thu hẹp được khoảng trống giữa việc thay đổi trạng thái nghiệp vụ và việc ghi nhận rằng event tương ứng cần được gửi đi.

Tuy nhiên, Transactional Outbox không làm cho event trùng lặp biến mất. Một tình huống vẫn có thể xảy ra như sau:

1. Relay publish event thành công.
2. Message broker xác nhận đã nhận event.
3. Relay gặp sự cố trước khi cập nhật bản ghi outbox thành sent.
4. Bản ghi vẫn giữ trạng thái pending.
5. Khi khởi động lại, relay đọc bản ghi này và publish event thêm một lần nữa.

Trong tình huống trên, message broker có thể nhận cùng một event nhiều lần. Đây không hẳn là lỗi của Outbox, mà là hệ quả của việc hệ thống ưu tiên không làm mất event khi kết quả publish chưa được lưu lại đầy đủ.

Vì vậy, Transactional Outbox thường cung cấp at-least-once publication, tức event được publish ít nhất một lần nhưng có thể xuất hiện nhiều lần. Pattern này giúp xử lý khoảng trống dual-write, nhưng không tự bảo đảm rằng consumer chỉ xử lý event một lần hoặc toàn bộ quy trình phía sau chỉ tạo ra một kết quả nghiệp vụ. Để đạt được mục tiêu đó, các service nhận event vẫn cần sử dụng mã event ổn định, tính idempotency và cơ chế chống xử lý trùng lặp.

Dedupe ở từng hop trong event pipeline

Cơ chế chống trùng (dedupe) cần được triển khai tại từng chặng (hop) trong luồng xử lý event, vì trùng lặp có thể phát sinh ở bất kỳ ranh giới nào chứ không chỉ tại điểm tiếp nhận ban đầu. Provider có thể gửi lại webhook, relay có thể publish lại sau sự cố, message broker có thể giao lại event, còn delivery worker có thể thực hiện lại một job chưa được xác nhận hoàn tất. Mỗi chặng, hay hop, chịu trách nhiệm cho một tác động riêng, chẳng hạn cập nhật trạng thái nghiệp vụ, tạo delivery record hoặc gửi request tới hệ thống bên ngoài. Vì vậy, mỗi hop cần có mã nhận diện ổn định và cơ chế chống trùng phù hợp để bảo đảm cùng một event không làm lặp lại phần công việc mà chặng đó kiểm soát.

Hop 1: Inbound event

Provider event ID nên được lưu với unique constraint.

Trong cùng transaction, service có thể:

1. Insert provider event ID.
2. Cập nhật subscription hoặc payment state.
3. Tạo canonical outbox event.
4. Commit.

Nếu event ID đã tồn tại, handler kiểm tra trạng thái đã lưu và trả success mà không chạy lại business transition.

Hop 2: Outbox relay

Nhiều relay workers có thể claim các outbox rows song song.

PostgreSQL cho phép dùng FOR UPDATE SKIP LOCKED để worker bỏ qua những row đang bị worker khác lock. Tài liệu PostgreSQL lưu ý rằng cơ chế này phù hợp với queue-like tables, dù nó tạo một view không nhất quán và không nên dùng như query pattern chung.

SELECT id
FROM outbox_events
WHERE status = 'pending'
ORDER BY id
LIMIT 20
FOR UPDATE SKIP LOCKED;

Cơ chế này giảm duplicate do hai workers cùng claim một row tại cùng thời điểm. Nó không loại bỏ duplicate do crash sau khi publish.

Publisher confirms cho relay biết broker đã nhận trách nhiệm với message. RabbitMQ mô tả publisher confirms là acknowledgement mechanism giữa broker và publisher.

publish(event)

if broker did not confirm:
    keep event pending
    retry later

if broker confirmed:
    mark event sent

Giữa broker confirm và mark sent vẫn còn một failure boundary. Vì vậy, canonical event ID phải được giữ nguyên khi publish lại.

Hop 3: Fan-out

Giả sử một canonical event cần được gửi tới năm endpoints. Fan-out service nên tạo mỗi logical delivery theo unique key:

(event_id, endpoint_id)

Khi event bị replay:

• Ba deliveries đã thành công, không cần tạo lại.
• Hai deliveries còn pending có thể tiếp tục được enqueue.
• Không tạo thêm năm delivery records mới.

Idempotency ở đây không chỉ có nghĩa là “không crash khi insert duplicate”. Nó có nghĩa là không lặp lại phần công việc đã hoàn tất.

Hop 4: Giao thức HTTP và receiving consumer

Delivery worker nên kiểm tra trạng thái trước khi gửi:

delivery = load(delivery_id)
if delivery.status is succeeded or dead_lettered:    return
send_http_request(delivery)

Việc kiểm tra này cần thiết nhưng chưa đủ.

Failure vẫn có thể xảy ra:

HTTP endpoint processes request successfully
        ↓
response bị mất hoặc worker crash
        ↓
local delivery vẫn là pending
        ↓
worker retry request

Bên gửi không thể chắc chắn rằng request đầu tiên chưa được xử lý, vì phía nhận có thể đã tạo ra tác động nghiệp vụ nhưng phản hồi lại bị mất. Do đó, mỗi lần gửi lại cần sử dụng cùng một idempotency key hoặc mã event chuẩn để phía nhận nhận diện đây là cùng một thao tác và bỏ qua phần xử lý đã hoàn tất. 

Tuy nhiên, việc bảo đảm một event chỉ tạo ra một kết quả nghiệp vụ ở phía nhận cuối cùng vẫn phụ thuộc vào cách hệ thống đó triển khai idempotency và cơ chế chống xử lý trùng lặp.

Luồng xử lý tham khảo cho billing và subscription với MonetKit

MonetKit hỗ trợ quản lý subscription, sản phẩm và trạng thái khách hàng trên App Store, Google Play và Stripe. Trong một kiến trúc phù hợp, các event từ từng nhà cung cấp có thể được chuẩn hóa thành một định dạng subscription event thống nhất trước khi phân phối tới các service phía sau.

Luồng dưới đây được xây dựng dựa trên use case của sản phẩm và chỉ mang tính tham khảo. Đây không phải là mô tả đã được xác minh về kiến trúc production hiện tại của MonetKit.

Giai đoạn 1: Tiếp nhận và xử lý event từ nhà cung cấp

Khi nhận được webhook từ Stripe, App Store hoặc Google Play, hệ thống có thể xử lý theo các bước sau:

1. Xác minh chữ ký của nhà cung cấp để bảo đảm webhook hợp lệ.
2. Lấy mã event ổn định do nhà cung cấp cung cấp.
3. Kiểm tra loại event và nội dung payload.
4. Ghi bản ghi chống trùng lặp vào database, sử dụng unique constraint để ngăn cùng một event được tiếp nhận nhiều lần.
5. Cập nhật trạng thái giao dịch hoặc subscription.
6. Xác định quyền truy cập cần được cấp, thay đổi hoặc thu hồi.
7. Tạo một canonical event, tức event đã được chuẩn hóa theo định dạng chung của hệ thống, rồi ghi vào bảng outbox.
8. Commit toàn bộ thay đổi trong cùng một database transaction.

Một canonical event có thể có cấu trúc như sau:

{
  "event_id": "canonical-subscription-event-id",
  "event_type": "subscription.entitlement_changed",
  "provider": "stripe",
  "provider_event_id": "provider-event-id",
  "subscription_id": "subscription-id",
  "entitlement_state": "active",
  "occurred_at": "provider-event-time",
  "schema_version": 1
}

Các trường dữ liệu cụ thể trong event cần được xác minh theo event contract chính thức của MonetKit.

Giai đoạn 2: Relay publish canonical event

Sau khi database transaction hoàn tất, relay sẽ đọc canonical event từ bảng outbox và publish lên message broker.

Nếu quá trình publish bị timeout hoặc relay không nhận được xác nhận từ broker, hệ thống nên:

• Giữ bản ghi ở trạng thái có thể retry.
• Tiếp tục sử dụng cùng một event_id, không tạo mã mới.
• Áp dụng chính sách retry kết hợp backoff để tránh gửi lại liên tục.
• Ghi nhận số lần thử và lỗi gần nhất để phục vụ theo dõi, cảnh báo và xử lý sự cố.

Một tình huống khác vẫn có thể xảy ra: broker đã nhận event, nhưng relay gặp sự cố trước khi lưu trạng thái sent vào database. Khi khởi động lại, relay có thể publish cùng event thêm một lần nữa. Việc giữ nguyên event_id giúp các service phía sau nhận diện đây là bản gửi lại của cùng một event, thay vì một thao tác nghiệp vụ mới.

Giai đoạn 3: Fan-out và xử lý tại các consumer

Sau khi được publish, canonical event có thể được phân phối tới nhiều thành phần khác nhau, chẳng hạn:

• Entitlement service để cấp hoặc thu hồi quyền truy cập.
• Analytics pipeline để ghi nhận dữ liệu sử dụng và doanh thu.
• Notification service để gửi thông báo tới người dùng.
• Customer webhook service để chuyển event tới hệ thống của khách hàng.
• Quy trình audit hoặc reconciliation để kiểm tra và đối soát dữ liệu.

Mỗi consumer cần triển khai idempotency theo đúng tác động nghiệp vụ mà nó chịu trách nhiệm.

Ví dụ, Entitlement service có thể dùng cặp (event_id, entitlement_type) để tránh cấp cùng một quyền nhiều lần. Customer webhook service có thể dùng (event_id, endpoint_id) để không tạo trùng một lượt gửi tới cùng endpoint. Với Analytics, hệ thống có thể lưu dữ liệu thô có chứa bản trùng, nhưng cần loại bỏ bản trùng trước khi tổng hợp số liệu nếu yêu cầu dữ liệu đòi hỏi tính chính xác.

Cách triển khai cụ thể phụ thuộc vào yêu cầu của từng consumer, nhưng nguyên tắc chung vẫn là giữ nguyên mã event xuyên suốt pipeline và chống xử lý trùng tại mỗi chặng có tạo ra tác động thực tế.

Lợi ích của at-least-once delivery kết hợp với idempotency

At-least-once delivery kết hợp với idempotency giúp hệ thống có thể retry khi kết quả chưa rõ ràng mà không làm lặp lại tác động nghiệp vụ. Message vẫn có thể được gửi nhiều lần, nhưng mỗi logical operation chỉ nên tạo ra một kết quả trong phạm vi đã xác định.

Cho phép retry an toàn hơn

Khi request bị timeout, bên gửi không biết phía nhận chưa xử lý hay đã xử lý thành công nhưng phản hồi bị mất. Bằng cách giữ nguyên idempotency key hoặc event ID trong mỗi lần retry, phía nhận có thể nhận diện đây là cùng một thao tác và bỏ qua phần xử lý đã hoàn tất.

Bảo vệ trạng thái nghiệp vụ quan trọng

Idempotency giúp giảm nguy cơ cùng một webhook hoặc message replay tạo nhiều payment records, entitlement, subscription updates hoặc ledger entries. Đây là lợi ích quan trọng nhất đối với các thao tác có chi phí cao hoặc khó hoàn tác.

Cải thiện khả năng phục hồi

Các công việc chưa hoàn tất có thể được lưu ở trạng thái pending và tiếp tục sau khi service khởi động lại hoặc một dependency tạm thời gặp lỗi. Điều kiện là trạng thái xử lý phải được lưu bền vững và mọi lần retry đều dùng cùng một mã nhận diện.

Dễ theo dõi và điều tra sự cố

Event ID, trạng thái xử lý, số lần thử, lỗi gần nhất và timestamp tạo thành lịch sử rõ ràng cho từng thao tác. Nhờ đó, đội vận hành có thể biết event đã đi tới bước nào, vì sao bị retry và liệu tác động nghiệp vụ đã hoàn tất hay chưa.

Giảm sự phụ thuộc giữa các service

Producer không cần chờ mọi service phía sau xử lý xong trong request ban đầu. Entitlement, analytics, notification hoặc customer webhook có thể xử lý và retry độc lập theo chính sách lỗi riêng, giúp một sự cố cục bộ không làm gián đoạn toàn bộ quy trình.

Trade-offs và giới hạn

Mô hình này tăng độ tin cậy, nhưng đổi lại hệ thống phải chấp nhận thêm thao tác database, độ trễ, dữ liệu chống trùng và độ phức tạp vận hành.

Tăng số lần đọc, ghi và dung lượng lưu trữ

Mỗi chặng có thể cần unique constraint, processed-event record, delivery row và trạng thái retry. Với lưu lượng lớn, các bảng này cần được tối ưu về index, partitioning và cleanup.

Chấp nhận eventual consistency

Outbox, relay, queue và retry khiến trạng thái ở các service phía sau có thể được cập nhật chậm hơn so với hệ thống nguồn. Kiến trúc này ưu tiên không mất event và khả năng phục hồi hơn tính đồng bộ tức thời.

Duplicate vẫn tồn tại

Thiết kế không loại bỏ bản trùng trên đường truyền. Nó chỉ giúp hệ thống nhận diện duplicate và biến lần xử lý lại thành thao tác không tạo thêm thay đổi.

Cần quản lý thời gian lưu dữ liệu chống trùng

Nếu xóa dedupe record quá sớm, một event cũ có thể bị xử lý lại. Nếu giữ vô thời hạn, storage sẽ tiếp tục tăng. Thời gian lưu cần dựa trên retry window, replay policy và yêu cầu kiểm toán.

Idempotency không giải quyết event sai thứ tự

Một event subscription.updated cũ vẫn có thể đến sau subscription.canceled. Để xử lý trường hợp này, hệ thống có thể cần sequence number, version, timestamp, truy vấn nguồn dữ liệu chính hoặc kiểm tra tính hợp lệ của state transition.

Hệ thống bên ngoài vẫn nằm ngoài quyền kiểm soát

Bên gửi có thể cung cấp stable idempotency key, nhưng không thể buộc phía nhận sử dụng key đó đúng cách. Exactly-once effects ở hệ thống cuối cùng vẫn phụ thuộc vào cách consumer lưu key và cập nhật trạng thái nghiệp vụ.

Không phải tác động nào cũng hoàn tác được

Email, SMS hoặc thao tác qua external API có thể đã xảy ra và không thể rollback. Khi đó, hệ thống cần thêm idempotent provider API, operation ledger, reconciliation hoặc compensation strategy.

Tóm lại, at-least-once delivery kết hợp với idempotency phù hợp khi việc mất hoặc xử lý trùng event đều gây hậu quả đáng kể. Đổi lại, hệ thống phải đầu tư thêm vào lưu trạng thái, theo dõi, retry và cơ chế chống trùng tại từng service.

Khi nào nên sử dụng at-least-once delivery kết hợp với idempotency?

At-least-once delivery kết hợp với idempotency phù hợp khi hệ thống không được phép làm mất thao tác, nhưng việc xử lý cùng một thao tác nhiều lần cũng có thể gây hậu quả nghiêm trọng. Mô hình này cho phép message được gửi lại khi kết quả chưa rõ ràng, đồng thời dùng mã nhận diện ổn định và cơ chế chống trùng để mỗi thao tác nghiệp vụ chỉ tạo ra một kết quả trong phạm vi đã xác định.

Cách tiếp cận này đặc biệt cần thiết với những nghiệp vụ liên quan đến tiền, quyền truy cập, số dư hoặc dữ liệu cần kiểm toán, chẳng hạn:

• Thanh toán và hoàn tiền: Tránh ghi nhận một giao dịch hoặc thực hiện hoàn tiền nhiều lần từ cùng một event.
• Kích hoạt, gia hạn và hủy subscription: Bảo đảm một thay đổi từ nhà cung cấp thanh toán không cập nhật trạng thái subscription nhiều lần.
• Cấp hoặc thu hồi entitlement: Tránh cấp trùng quyền truy cập hoặc thu hồi quyền do xử lý lại cùng một event.
• Xử lý ledger và invoice: Ngăn một giao dịch tạo nhiều dòng sổ cái hoặc nhiều hóa đơn.
• Giữ chỗ hàng tồn kho: Hạn chế việc một đơn hàng giữ hoặc trừ cùng một lượng hàng nhiều lần.
• Xử lý và hoàn tất đơn hàng: Tránh tạo trùng shipment, payment record hoặc yêu cầu thực hiện đơn hàng.
• Gửi webhook tới khách hàng: Cho phép retry khi endpoint không phản hồi, nhưng vẫn giữ nguyên mã event để phía nhận chống xử lý trùng.
• Đồng bộ trạng thái giữa các service: Giảm nguy cơ cùng một event làm thay đổi dữ liệu nhiều lần ở các hệ thống phía sau.
• Các thao tác cần audit: Tạo lịch sử rõ ràng về event, số lần xử lý, trạng thái và kết quả cuối cùng.

Mô hình này cũng phù hợp khi hệ thống giao tiếp qua mạng với nhiều thành phần độc lập, chẳng hạn payment provider, message broker, external API hoặc hệ thống của khách hàng. Ở những ranh giới này, timeout và mất phản hồi khiến bên gửi không thể biết chắc lần xử lý trước đã thành công hay chưa.

Khi nào có thể không cần triển khai đầy đủ?

Không phải mọi event đều cần một pipeline gồm outbox, relay, retry, bảng chống trùng và dead-letter queue. Nếu chi phí của việc mất hoặc xử lý trùng event thấp, một thiết kế đơn giản hơn có thể phù hợp và dễ vận hành hơn.

Có thể không cần triển khai đầy đủ khi:

• Dữ liệu chỉ là telemetry có giá trị thấp: Việc mất hoặc trùng một vài event đo lường không ảnh hưởng trực tiếp đến nghiệp vụ.
• Duplicate có thể được loại bỏ khi tổng hợp: Dữ liệu thô có thể chứa bản trùng nhưng hệ thống sẽ chống trùng trước khi tính báo cáo.
• Thao tác vốn đã có tính idempotent: Ví dụ, request PUT đặt trạng thái về một giá trị tuyệt đối thường có thể chạy lại mà không tạo thêm kết quả.
• At-most-once phù hợp hơn: Một thông báo bị bỏ lỡ có thể chấp nhận được, trong khi gửi trùng lại gây phiền hoặc tạo rủi ro lớn hơn.
• Toàn bộ thay đổi nằm trong một database transaction: Nếu không có message broker hoặc external side effect, một local transaction đơn giản có thể đã đủ.
• Có thể đối soát lại từ nguồn dữ liệu chính: Hệ thống có thể định kỳ đọc lại trạng thái từ một nguồn đáng tin cậy và sửa các sai lệch.
• Luồng xử lý có lưu lượng thấp và dễ sửa thủ công: Chi phí triển khai một cơ chế phân tán phức tạp có thể cao hơn chi phí xử lý các sự cố hiếm gặp.

Khi lựa chọn, nên đánh giá đồng thời ba yếu tố:

1. Chi phí nếu event bị mất.
2. Chi phí nếu cùng một effect xảy ra nhiều lần.
3. Chi phí kỹ thuật để xây dựng và vận hành cơ chế chống trùng.

Thiết kế phù hợp không nhất thiết phải cung cấp mức bảo đảm mạnh nhất. Quan trọng hơn là chọn mức bảo đảm tương xứng với giá trị của thao tác nghiệp vụ và hậu quả khi thao tác đó bị bỏ sót hoặc lặp lại.

Kết luận

Sự khác nhau quan trọng nhất giữa at-least-once và exactly-once nằm ở đối tượng và phạm vi được bảo đảm. At-least-once delivery mô tả việc message có thể được gửi lại khi kết quả của lần gửi trước chưa rõ ràng. Exactly-once effects mô tả mục tiêu ở tầng nghiệp vụ: một thao tác logic chỉ được phép thay đổi trạng thái một lần trong phạm vi mà hệ thống kiểm soát.

Transactional Outbox giúp giảm nguy cơ mất event giữa database và message broker, nhưng không loại bỏ bản trùng. Idempotency tiếp tục xử lý phần còn lại bằng cách nhận diện các lần retry và ngăn chúng tạo thêm tác động nghiệp vụ.

Với các hệ thống payment và subscription như MonetKit, cách tiếp cận thực tế là giữ nguyên mã event, chống trùng tại từng chặng và xác định rõ phạm vi của mỗi guarantee. Mục tiêu không phải là làm cho message chỉ xuất hiện một lần, mà là bảo đảm các lần gửi lại không làm sai lệch trạng thái hệ thống.

FAQs