Your Frontend Shouldn't Trust a Single Click

One of the most expensive production bugs isn't caused by a bad algorithm. It's caused by a second click.

A user clicks "Place Order."

• Nothing happens for a second.
• So they click again.
• Or refresh the page.
• Or their browser automatically retries the request after a network interruption.

From the user's perspective, they made one purchase. From the system's perspective, it may have received multiple requests.

This is why resilient frontend applications don't assume every action happens exactly once.

Some simple practices make a huge difference: ✓ Disable critical actions while a request is in progress. ✓ Show immediate feedback so users know something is happening. ✓ Prevent accidental duplicate submissions. ✓ Send idempotency keys for operations that must execute only once. ✓ Design for unreliable networks, not perfect ones.

One lesson that's changed how I approach frontend architecture: The frontend is the first line of defense against duplicate actions.

But it shouldn't be the only one.

• Users can refresh pages.
• Browsers can retry requests.
• Networks can behave unpredictably.

That's why great systems protect against duplicate operations at both the frontend and backend.

• The frontend improves the experience.
• The backend guarantees correctness.
• Both matter.

Have you ever encountered a production issue caused by duplicate requests or repeated user actions?