Ensuring API Idempotency: Prevent Duplicate Requests in Scalable Systems

Improving a system’s capacity to handle more users involves two complementary directions: upgrading the hardware architecture—using cloud services such as load balancers, cloned virtual machines, managed databases, and object storage—and optimizing the software architecture through clean code practices, business decoupling, micro‑services, stateless design, and shared file storage.

Idempotency

Effect : The same API endpoint should return identical results for multiple requests, except when network failures occur.

Purpose : To avoid business duplication caused by repeated requests.

Duplicate Request Scenarios

1. The client’s first request succeeds on the server but the response is lost due to a network error, prompting the client to resend the request.

2. The user rapidly clicks a submit button, causing the same request to be sent multiple times.

In simple terms, most business logic can be categorized as create, read, update, or delete operations.

Read operations are inherently idempotent because they do not modify state.

Delete operations are also safe to repeat, though some systems prefer to report success rather than “not found” on subsequent attempts.

Create and Update operations require careful handling: creation must avoid duplicate records, and updates should prevent unnecessary repeated modifications.

Implementing Idempotency

Method : The client includes a unique identifier with each request; the server checks this identifier and, if it has already processed the request, returns the original response.

Example : When opening an “Add” form, generate an AddId token and submit it together with the form data. The backend uses AddId as a cache key to store the response. If the user clicks the add button multiple times, the server recognizes the repeated AddId and returns the cached result.

The AddId is refreshed only after a successful save and the form is cleared, ensuring that subsequent submissions generate a new identifier.

That concludes today’s sharing on idempotency.