Preventing Duplicate Orders: Front‑End Intercept and Redis Idempotency Strategies

1. Analyze the Duplicate Order Problem

In real‑world e‑commerce systems, users may click the order button repeatedly within a short time, or service retry policies and network congestion can cause the order service to receive multiple identical requests, leading to duplicate orders that waste resources and damage user experience.

2. Idempotency Solutions

2.1 Front‑End Interception

After the first click on the "Buy" button, disable the button to prevent further clicks, as illustrated below.

This method only works for UI‑based requests; if the client calls the backend API directly, the front‑end guard is ineffective.

2.2 Using Redis SETNX

Redis SETNX returns true only when the key does not already exist, allowing us to guarantee that a value is stored only once. The workflow is:

Generate a unique key for the user‑order combination.

Call SETNX key value. If it returns true, proceed with order creation.

Set an expiration (e.g., 5 seconds) to limit the window for duplicate attempts.

The key composition includes:

User token (unique identifier after login)

Product URL (identifies the item being purchased)

A constant string to distinguish order‑related idempotency from other operations

Even if the client calls the order API multiple times, only the first successful SETNX will allow order creation; subsequent attempts fail and are ignored.

2.3 Redis Token Approach

When the order confirmation page is rendered, the server generates a one‑time anti‑duplicate token (e.g., a UUID) and stores it in Redis with an expiration time.

The client must submit this token with the order request. The server checks Redis:

If the token exists, the request is valid; delete the token (using a distributed lock if necessary) and create the order.

If the token is missing, treat the request as a duplicate and ignore it (or log it).

3. Summary and Recommendations

(1) Combine front‑end button disabling with one of the Redis‑based backend solutions to achieve robust duplicate‑order prevention.

(2) Add a database‑level fallback, such as a unique constraint on an order identifier, to catch any remaining edge cases.