Don't Trust the Client: How I Hacked My Own Coupon System

Aditya — Tue, 06 Jan 2026 03:59:58 +0000

I recently finished building a promotional engine for an e-commerce platform. The logic was simple: A "Flash Sale" coupon that expires in 2 hours.

I wrote the logic, tested it, and deployed it. It worked perfectly. Then, I decided to switch hats. I stopped being the developer and started being the bad actor.

The Hack I opened the application, applied the coupon, and saw the timer counting down. Then, I did something incredibly low-tech:

I went to my laptop's system settings and changed the date back by one day.

The Result? The coupon, which should have expired, became valid again. The "Expired" button turned back into "Apply." My backend accepted the order.

I had accidentally committed the cardinal sin of web development: I trusted the client.

The Technical Deep Dive In my initial code, I was validating the expiry logic partially on the client-side to save server resources (a "premature optimization"). I was comparing the coupon's expiry timestamp against new Date()—which pulls from the user's operating system, not the server.

If the user controls the OS, the user controls the time.

The Fix (Source of Truth) The solution wasn't just to move the check to the backend; it was to ensure the backend wasn't relying on its local clock either (which can drift in distributed systems).

I refactored the architecture to use the database (in this case, MongoDB) as the single source of temporal truth.

JavaScript

// The Bad Way (Vulnerable)
if (Date.now() < coupon.expiry) { ... }

// The Better Way (Database specific)
const validCoupon = await Coupon.findOne({
    code: "FLASH50",
    expiryDate: { $gt: new Date() } // Server time is strictly enforced
});

The Lesson "Frontend validation is for User Experience. Backend validation is for Security."

It’s a cliché for a reason. As engineers, we often focus on the happy path—when the user does what they are supposed to do. But the real engineering happens when we account for the user who is trying to trick the system.

Always assume your API is being called by a script, not a browser.

Beyond if (stock > 0): Handling Race Conditions in High-Traffic E-Commerce Systems

Aditya — Tue, 06 Jan 2026 03:47:02 +0000

Why basic logic fails at scale and how to implement Optimistic Concurrency Control in Node.js & MongoDB.

In the early stages of building an e-commerce application, inventory management seems straightforward. Logic dictates: check if the item is in stock, and if it is, process the order and decrement the count.

It usually looks something like this:

// The Naive Approach
const product = await Product.findById(productId);

if (product.stock > 0) {
  product.stock -= 1;
  await product.save();
  // Process payment...
} else {
  throw new Error('Out of stock');
}

In a development environment, this works perfectly. In a production environment with concurrent users, this is a disaster waiting to happen.

The Problem: The Race Condition Imagine two users, Alice and Bob, try to buy the last iPhone at the exact same millisecond.

Thread A (Alice) reads the DB: Stock = 1.

Thread B (Bob) reads the DB: Stock = 1.

Thread A passes the if check and decrements stock to 0.

Thread B also passes the if check (because it read the stale data before Thread A finished) and decrements stock to -1.

We have now sold two phones when we only had one. This leads to customer support nightmares and reconciliation issues.

The Experienced Solution: Atomic Operations To solve this without locking the entire database (which kills performance), we leverage the atomicity of the database engine itself. Instead of a "Read-Modify-Write" pattern in the application layer, we push the logic to the database layer.

In MongoDB (Mongoose), we can use findOneAndUpdate with a query filter that acts as our guard:

JavaScript

// The Scalable Approach
const updatedProduct = await Product.findOneAndUpdate(
  { 
    _id: productId, 
    stock: { $gt: 0 } // The Atomic Guard
  },
  { 
    $inc: { stock: -1 } // The Atomic Update
  }, 
  { new: true }
);

if (!updatedProduct) {
throw new Error('Out of stock or race condition detected');
}
Why this works: The database process is linear. Even if two requests hit the database simultaneously, MongoDB will process one first. The first request matches the document because stock > 0. It decrements the stock. The second request immediately fails to match because stock is now 0.

Conclusion Building for scale requires moving beyond happy-path logic. By utilizing atomic database operations, we ensure data consistency without the overhead of pessimistic locking or queues, ensuring our application remains robust even during flash sales.

Forem: Aditya

Don't Trust the Client: How I Hacked My Own Coupon System

Beyond if (stock > 0): Handling Race Conditions in High-Traffic E-Commerce Systems