How to Prevent Duplicate Order Submissions in High‑Traffic E‑Commerce Systems

Duplicate Submission Causes

In e‑commerce interview scenarios, duplicate order submission is a frequent problem, second only to flash‑sale implementations. Two main reasons trigger it:

Users click the order button repeatedly or refresh the browser within a short time.

Gateway layers such as Nginx or Spring Cloud Gateway perform timeout retries.

Common Solutions

Solution 1: Disable the Order Button

This approach is common in registration or login flows, where a button (e.g., “Send verification code”) is greyed out for about a minute after being clicked. Some developers copy this pattern for order submission, which prevents rapid repeated clicks but does not address gateway‑level retries.

Solution 2: Pre‑Generate a Global Unique Order ID

Add a backend endpoint that returns a globally unique identifier (UUID or NanoID).

When the order page loads, the frontend calls this endpoint to obtain the ID.

Include the generated ID in the order‑creation request; a unique index on the database column rejects duplicate inserts.

Note: the global ID should not replace the primary key in sharded databases; an auto‑increment ID remains preferable for that purpose.

Solution 3: Frontend Generates a Global Unique Order ID

The frontend creates a unique order number (e.g., UUID) when the user opens the order page.

The same ID is sent with the order request, relying on the database’s unique index to block duplicates.

Solution 4: Business‑Level Idempotency Using Redis

Understanding the core of an order—"user + product"—leads to a Redis‑based lock. By constructing a key like userId:productId and setting it with SET key value NX EX seconds, the key exists only for a short window, preventing repeated submissions.

SET key value NX EX seconds

The workflow is:

On order submission, attempt to set the Redis key userId:productId with an expiration time.

If the command succeeds, continue with the normal order processing.

If it fails (key already exists), return a failure response to the client.

Conclusion

In a real production environment we selected Solution 4 (Redis‑based idempotency) because it required the smallest overall code change, limited the regression testing scope, and offered the lowest technical complexity while still fully preventing duplicate orders. This aligns with the principle of keeping systems simple and reliable.