Ensuring Idempotency with Unique IDs: UUID, Snowflake, and Shared Storage Strategies

Idempotency means that executing an operation multiple times has the same effect as executing it once, which is crucial for scenarios like user order placement where retries may occur due to timeouts.

To avoid duplicate orders, inventory deductions, or double charging, each order should carry a unique identifier. The downstream service can record the status of each request and reject repeated executions when the identifier has already been processed.

Unique IDs can be generated either by a centralized ID allocation service or by the upstream service itself. Common approaches include using a MySQL auto‑increment column, UUIDs, or distributed algorithms such as Twitter's Snowflake.

UUID (Universally Unique Identifier) is a 128‑bit value that, while not guaranteeing absolute uniqueness, has an astronomically low collision probability. Its drawbacks are large size, unreadability, and lack of monotonic ordering.

Snowflake generates a 64‑bit long ID composed of a 41‑bit timestamp, a 10‑bit machine identifier, and a 12‑bit sequence number, allowing up to 4096 IDs per millisecond per node and supporting up to 1024 nodes.

When the idempotency service is distributed, the unique IDs must be stored in shared storage so that each instance remains stateless. Options include MySQL or key‑value stores like Redis; the author uses Redis for this purpose.

Not every request is a duplicate, so checking for an existing ID on every call can be wasteful. With MySQL you can attempt an INSERT ... ON DUPLICATE KEY UPDATE and infer existence from the result; with Redis you can use SETEX to atomically create the key only if it does not already exist.

Overall, the service itself should ensure idempotency rather than delegating that responsibility to callers.