Every promotion carries a number somebody in finance agreed to. Ten percent off, capped at two thousand, with a hundred thousand of budget. The campaign goes live and one of two things goes wrong.
Either the cap is not enforced, and the spend is discovered in a reconciliation weeks later. Or it is enforced, strictly, at checkout — and the shopper who arrives one order after the budget is exhausted gets an error saying their valid code is not valid.
Both are bad. They are also usually treated as the same problem with a severity dial, which is why teams oscillate between them.
Two different races
They are not the same problem, because they involve different scarce resources.
A budget is a soft, aggregate limit. Nobody can tell from outside how much is left, the number moves continuously, and crossing it by a few thousand rupees is a variance to review — not a customer-facing event.
A single-use code is a hard, discrete resource. There is exactly one, and if two shoppers both spend it you have promised something twice. The customer can reason about this: a code that has been used is intuitively gone.
Conflating them produces the failure modes above. Treat the budget like the code and you reject people arbitrarily. Treat the code like the budget and you double-issue.
Scarce codes get a reservation
For codes with genuine scarcity, xMatix holds the code for the duration of a checkout. At most one hold is active at a time; it expires on its own if the shopper wanders off, so an abandoned checkout does not retire a code permanently.
This is deliberately not applied to every code. A campaign-wide code that thousands of people may use has no contention worth serialising, and adding a hold per checkout would buy nothing but latency. Reservation is a flag on the code, set for the cases that need it.
Budgets get place-and-flag
For the budget, the order completes. The redemption is recorded and flagged as having crossed the cap.
That will read as wrong to anyone who has been asked to enforce a limit. The argument for it is about who bears the cost of the ambiguity. A shopper cannot see the budget, cannot know how much is left, and did nothing different from the person served ninety seconds earlier. Refusing them converts an internal accounting concern into a customer-facing failure at the worst possible moment — mid-checkout, on a decision they had already made.
The overspend is a number a human reviews. The rejection is a customer you do not get back. Given a choice about where to put the imprecision, put it in the ledger.
The flag is what makes this defensible rather than sloppy. Overspend is not absorbed silently: the campaign carries the spend and an overspent marker, and the redemptions that crossed the line are individually identifiable. Someone decides what to do — pause the campaign, raise the cap, absorb it — with the specific orders in front of them.
The same instinct, twice
This is the same reasoning that governs checkout in the same system. There, the commercial snapshot is frozen before the gateway is asked for money, so that a captured payment can always become an order — pushing every possible failure to the side of the line where the customer has not yet paid.
Here, the budget check is allowed to be approximate at the edge, so that no shopper is refused for arithmetic they cannot see — pushing the imprecision to the side where a person can review it.
Both come from asking the same question before writing the rule: when this goes wrong, who finds out, and what can they do about it? A finance analyst reviewing a flagged overspend can act. A customer staring at "coupon not valid" can only leave.
The part worth stealing
Not the specific policy — yours may differ, and a genuinely hard cap is sometimes the right call for a loss-leading offer.
The part worth stealing is refusing to enforce every limit with the same mechanism. Work out, per constraint, whether it is discrete or aggregate, whether the customer can perceive it, and who is best placed to resolve a breach. You will usually find that the constraints your customer can reason about should be enforced strictly, and the ones they cannot should be recorded and reviewed.