标签：#idempotency

Treat an SMS timeout as an unknown outcome, not a failed send: accept each password-reset event once, persist its expiry and idempotency key before dispatch, and retry only through a worker that can reconcile the original attempt. For a short-lived e-commerce reset token, compliance evidence is the deciding constraint. The system must be able to show what it accepted, what it attempted, when it stopped, and why, without storing the token or message body in an audit log. This changes the shape of the endpoint. A Node.js Express handler may receive the event, but it shouldn't hold the HTTP request open while an SMS provider decides the final delivery state. Return an accepted response after durable admission, then expose status from local state. The Go example below shows the same transport-independent contract because the hard part isn't an Express API call; it's controlling ownership of retries. One event, one logical notification. How should event notifications handle SMS timeout, retry, and duplicate sends? Use two identifiers with different jobs. event_id identifies the business action, such as one password-reset request. idempotency_key identifies the logical notification command. A unique constraint on the key makes two concurrent HTTP requests converge on one stored record; checking memory before an insert is not enough because two processes can pass that check together. A timeout leaves three possible realities: the provider never accepted the request, it accepted the request but the response was lost, or it accepted and sent the message before the caller stopped waiting. Retrying immediately as though the first case were certain is how customers receive two reset messages. Declaring success is no better. The durable record should therefore enter dispatch_unknown , keep the provider's attempt identifier when one exists, and move through reconciliation before another send can be authorized. Status polling serves a different purpose from retry. Polling reads th

Safe retry: idempotency key để retry một request không biến thành hai lần charge Trong hệ phân tán, retry là mặc định — client, gateway, load balancer, queue consumer đều retry khi timeout hoặc lỗi tạm thời. Vấn đề là nhiều thao tác quan trọng không idempotent tự nhiên: một request POST /charges gửi hai lần thì trừ tiền khách hai lần, một message OrderCreated xử lý hai lần thì ship hai đơn. Idempotency key là cơ chế để server nhận diện "cùng một intent" giữa các lần retry và chỉ thực hiện side effect một lần , trong khi vẫn trả về response giống hệt cho mọi lần gọi lặp — về mặt hiệu ứng thấy được từ bên ngoài, đây là cái người ta hay gọi là "exactly-once effect" (dù ở tầng transport vẫn là at-least-once). Cơ chế hoạt động Client sinh một identifier duy nhất cho mỗi thao tác (thường là UUIDv4) và đính kèm request — quy ước phổ biến là HTTP header Idempotency-Key (Stripe API dùng đúng tên này, và IETF có draft draft-ietf-httpapi-idempotency-key-header chuẩn hoá cùng tên header). Server dùng key làm identity của thao tác trong một cửa sổ TTL: Nhận request với key K . Tra K trong idempotency store. Nếu tồn tại và request cũ ở trạng thái terminal (đã có response), trả lại response đã lưu — không chạy lại business logic. Nếu tồn tại nhưng đang in-flight , trả 409 Conflict (hoặc chờ, tuỳ contract). Nếu chưa tồn tại, INSERT bản ghi với unique constraint trên key, chạy business logic, persist response, commit. Điểm cốt lõi là bước insert + bước business logic + bước lưu response phải nằm trong cùng một transaction boundary — hoặc chí ít, phải có cơ chế đảm bảo không có window mà một retry khác nhìn thấy "chưa có key" trong lúc lần đầu vẫn đang chạy dở. CREATE TABLE idempotency_keys ( key TEXT NOT NULL , user_id BIGINT NOT NULL , request_hash TEXT NOT NULL , -- fingerprint payload status TEXT NOT NULL , -- in_flight | succeeded | failed response_code INT , response_body JSONB , created_at TIMESTAMPTZ NOT NULL DEFAULT now (), locked_until TIMESTAMPTZ , PRIMARY KEY ( user_id ,