Bài 11: Idempotency & Retry An Toàn

Bài 10 kết luận rằng cách tránh lock mạnh nhất là làm cho việc lặp lại trở nên vô hại. Bài này là cách làm điều đó — và nó cũng là câu trả lời cho một bài toán mà mọi hệ thống phân tán phải đối mặt: khi client nhận timeout, nó không thể biết request đã được xử lý hay chưa.

Lab của bài này bắn 78.774 request đồng thời với cùng một idempotency key vào một endpoint trừ tiền. Kết quả: đúng một bản ghi trong database, đúng một mã 201 Created, và số dư bị trừ đúng một lần. Tắt idempotency đi và chạy lại cùng tải: 14.236 bản ghi, số dư bị trừ 1.423.600 — tài khoản âm 423.600.

11.1 Vì sao "exactly-once" là ảo tưởng

Client gửi một request trừ tiền. Nó chờ, và nhận timeout. Câu hỏi: server đã trừ tiền chưa? Client không có cách nào biết. Ba tình huống sau đây tạo ra đúng cùng một trải nghiệm ở phía client:

Đây là bài toán hai vị tướng: không có giao thức nào cho phép hai bên đạt được sự chắc chắn tuyệt đối về việc thông điệp đã tới, khi kênh truyền có thể mất tin. Hệ quả: exactly-once delivery là bất khả thi.

Nhưng có một tổ hợp làm được điều mà người ta thật sự muốn: at-least-once delivery + xử lý idempotent. Gửi lại cho tới khi chắc đã tới (at-least-once), và thiết kế sao cho nhận nhiều lần cũng chỉ có hiệu ứng một lần. Kết quả nhìn từ ngoài giống exactly-once, dù không có bước nào trong đó là exactly-once.

11.2 Idempotency key và bảng dedup

Cơ chế rất gọn: client sinh một key duy nhất cho ý định của mình — không phải cho từng lần thử. Server lưu ánh xạ key → kết quả vào một bảng dedup (dedup = deduplication, chống trùng: một bảng chỉ để nhớ "key này đã xử lý rồi, và đây là kết quả"). Gặp lại key đã có, server trả về kết quả cũ thay vì xử lý lại.

11.3 Ghi dedup và xử lý nghiệp vụ phải nằm trong CÙNG một transaction

Đây là mục quan trọng nhất của bài. Cách cài đặt trực giác nhất — và sai — trông như thế này:

// ===== WRONG: check-then-act — the classic race condition =====
const seen = await db.query(`SELECT * FROM charges WHERE idem_key = $1`, [key]);
if (seen.rows.length) return seen.rows[0].response;   // (1) check

await db.query(`UPDATE balances SET balance = balance - $1 WHERE id = 1`, [amount]);
await db.query(`INSERT INTO charges (idem_key, response) VALUES ($1, $2)`,
  [key, resp]); // (2) write

// The window between (1) and (2): TWO concurrent requests both see "not there" at (1),
// so BOTH proceed and BOTH charge. Exactly what we set out to prevent.

Lời giải không phải là thêm lock (xem Bài 10) mà là để database tự thực thi tính duy nhất, bằng một UNIQUE constraint, và làm cả hai việc trong một câu lệnh:

-- CTE: `ins` tries to write the dedup row. ON CONFLICT DO NOTHING means that if the
-- key already exists nothing is written and `ins` is EMPTY. `upd` only debits the
-- balance WHEN `ins` produced a row — so only the FIRST time has a business effect.
-- The final SELECT returns either the new result (created=true) or the STORED one.
--
-- It is ONE statement => Postgres runs it in an implicit transaction => there is NO
-- window for two concurrent requests to slip through.
WITH ins AS (
  INSERT INTO charges (idem_key, amount, response)
  VALUES ('order-999', 100, 'charge-ok-100')
  ON CONFLICT (idem_key) DO NOTHING
  RETURNING id, amount, response
), upd AS (
  UPDATE balances SET balance = balance - 100
  WHERE id = 1 AND EXISTS (SELECT 1 FROM ins)
  RETURNING balance
)
SELECT id, amount, response, 'true' AS created FROM ins
UNION ALL
SELECT c.id, c.amount, c.response, 'false' FROM charges c
WHERE c.idem_key = 'order-999' AND NOT EXISTS (SELECT 1 FROM ins);

Bảng charges có idem_key TEXT NOT NULL UNIQUE. Ràng buộc đó là thứ làm việc thật: nó biến việc chống trùng từ một đoạn code có thể sai thành một bất biến mà database không cho phép vi phạm.

Đo thật: 78.774 request đồng thời với cùng một key

64 kết nối, 10 giây, cùng một idem_key, so với cùng tải nhưng không có idempotency key:

Dòng "mã trả về" là bằng chứng gọn nhất: trong 78.774 request đồng thời cùng nhắm một key, đúng một request nhận 201 Created. Toàn bộ phần còn lại nhận 200 kèm chính kết quả đã lưu — cùng chargeId, cùng response. Không có request nào thất bại (0 lỗi).

11.4 Ngữ nghĩa HTTP, và hai tính chất hay bị gộp

Hai tính chất rất hay bị gộp làm một, và chúng độc lập với nhau:

Chú ý hai hàng cuối đối nghịch nhau: SET thì idempotent nhưng không giao hoán; += 1 thì giao hoán nhưng không idempotent. Trong hệ phân tán bạn thường cần cả hai, và cách đạt được là dùng phép cộng có kèm dedup — += 1 cho tính giao hoán, bảng dedup cho tính idempotent. Đây cũng là lời giải thích cho gợi ý ở Bài 9 mục 9.5: balance = balance + 50 trộn được còn SET balance = 150 thì không.

11.5 Idempotency ở tầng dữ liệu và cho consumer

Không phải lúc nào cũng cần một bảng dedup riêng. Nhiều khi tính idempotent có thể nằm sẵn trong cách bạn thiết kế dữ liệu:

Tự làm lại các phép đo

cd blog/sysdesign/sysdesign-lab
docker compose --profile replica up -d      # PostgreSQL is needed

psql_() { docker compose exec -T postgres psql -U lab -d lab -tAc "$1"; }
reset() { psql_ "TRUNCATE charges; UPDATE balances SET balance = 1000000 WHERE id = 1;"; }

# --- WITH an idempotency key: fire THE SAME key every time ---
reset
docker compose run --rm loadgen loadgen.js \
  --url "http://lb:8080/charge?key=order-999&amount=100&idem=1" -c 64 -d 10 -w 2 --json
psql_ "SELECT count(*) AS rows FROM charges;"               # 1
psql_ "SELECT balance FROM balances WHERE id=1;"            # 999900  (debited exactly 100)

# --- WITHOUT an idempotency key: same load, same duration ---
reset
docker compose run --rm loadgen loadgen.js \
  --url "http://lb:8080/charge?amount=100&idem=0" -c 64 -d 10 -w 2 --json
psql_ "SELECT count(*) AS rows FROM charges;"               # 14236
psql_ "SELECT balance FROM balances WHERE id=1;"            # -423600  (!)

# Look closely at the statusCodes field of the idempotent run: {"200":78773,"201":1}
# Exactly ONE request received 201 Created out of 78,774 concurrent requests.

Tóm lại

Exactly-once delivery là bất khả thi — bài toán hai vị tướng nói rằng client nhận timeout không thể phân biệt được ba tình huống khác nhau. Thứ khả thi và cũng là thứ người ta thật sự muốn là at-least-once + xử lý idempotent, và nhìn từ ngoài tổ hợp đó giống exactly-once.

Idempotency key phải là key cho ý định, do client sinh và giữ nguyên qua mọi lần thử. Server phải lưu toàn bộ kết quả chứ không chỉ một cờ "đã xử lý", và trả lại chính kết quả đó khi gặp key trùng.

Phần quan trọng nhất là mục 11.3: ghi dedup và xử lý nghiệp vụ phải nằm trong cùng một transaction. Không có thứ tự nào an toàn nếu tách làm hai — ghi dedup trước thì yêu cầu im lặng biến mất, xử lý trước thì lần thử lại trừ tiền thêm lần nữa. Và đừng dùng mẫu "kiểm tra rồi ghi": hai request song song đều thấy "chưa có". Cách rẻ nhất và chắc nhất là để UNIQUE constraint thực thi tính duy nhất, trong một câu lệnh duy nhất.

Đo thật: 78.774 request đồng thời cùng một key → đúng 1 bản ghi, đúng 1 mã 201, số dư trừ đúng 100, không một lỗi nào. Tắt idempotency: 14.236 bản ghi và số dư âm 423.600.

Bài 12 là nơi tất cả những điều trên trở thành điều kiện bắt buộc chứ không phải lựa chọn: message queue với ngữ nghĩa at-least-once. Khi một job có thể được giao lại bất cứ lúc nào, consumer phải idempotent — nếu không, mỗi lần redeliver là một lần side-effect nữa.