Ensuring Interface Idempotency: Concepts, Importance, and Practical Solutions

Idempotency

Idempotence is a mathematical and computer science concept where applying an operation twice yields the same result as applying it once. In the context of APIs, idempotency means that multiple identical requests should have the same effect as a single request.

Why Idempotency Is Needed

Repeated submissions are common in business development, caused by network issues, client retries, or UI glitches. In payment or order systems, duplicate submissions can create multiple orders or charge users repeatedly, leading to data inconsistency. In micro‑service architectures, external callers may retry due to network failures, so designing services to be idempotent prevents inconsistent state.

Idempotency Solutions

Database Unique Primary Key

Using a unique primary key (often a globally unique ID rather than an auto‑increment column) ensures that only one record with the same key can be inserted, providing idempotence for create operations.

CREATE TABLE `table_name` (
  `id` int NOT NULL AUTO_INCREMENT,
  `orderid` varchar(32) NOT NULL DEFAULT '' COMMENT '唯一id',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uq_orderid` (`orderid`) COMMENT '唯一约束'
) ENGINE=InnoDB;

When using this approach, the primary key should be a distributed global ID to guarantee uniqueness across services.

Database Optimistic Lock

An optimistic‑lock strategy adds a version column to a table. Each update checks the current version and increments it, ensuring that only one request can succeed when the version matches.

SELECT version FROM tablename WHERE xxx;

UPDATE tablename SET count = count + 1, version = version + 1 WHERE version = #{version};

PRG (Post/Redirect/Get) Pattern

The PRG pattern prevents duplicate form submissions by redirecting the client to a GET request after a successful POST, breaking the direct link between page refreshes and repeated POSTs.

Anti‑Repeat Token

Clients obtain a global token (e.g., from Redis) before invoking an operation. The token is sent in request headers; the server checks the token's existence and matches the associated user data, deletes the token, and proceeds with business logic. If the token is missing or mismatched, the request is rejected as a duplicate.

These solutions can be combined with front‑end request throttling or additional back‑end checks to ensure a single, consistent operation.

Finally, the author offers a comprehensive collection of architecture and interview materials for readers who wish to deepen their knowledge.