Every promotion is a rule waiting to be broken.
Coupons, stock, bundles and seller payouts change every week. Caches and queues make checkout fast, and also make it read numbers that are already out of date. Invarly checks the limits your margins depend on, on live data.
Why commerce breaks quietly
A checkout touches pricing, promotions, inventory, payments, fulfilment and, on a marketplace, seller balances. Promotions are configured by people outside engineering, often hours before a campaign, and each one is a new rule the code has to enforce.
When enforcement drifts, nothing fails. Orders go through, customers are happy, and the loss shows up in a margin report days later.
Five places it breaks
Coupons used past their cap
A limit check reads a cached or eventually consistent count. During a spike, the code keeps working long after the cap is reached.
The last unit sold twice
Two warehouses, two checkouts, or a reservation that never expires. Stock goes negative and someone gets a cancellation email.
Order totals that don’t add up
A discount change, a rounding fix or a new bundle type, and the stored total no longer matches the line items it was built from.
Refunds issued twice
Support refunds manually while an automated return flow refunds the same order.
Seller payouts on cancelled orders
A marketplace pays a seller for an order that was cancelled after the payout batch was calculated.
A walkthrough
Before a campaign, a deploy caches coupon lookups to speed up checkout. The limit check now reads the cached count.
- both coupons crossed their cap within 10 minutes of the deploy
- traced to 7be20d1 “cache coupon lookups”
checkout/coupon.go:41 - over-cap discount so far € 76.80
Seven redemptions over the cap instead of hundreds. The alert names the deploy, so the fix starts at the right diff.
The starter rule pack
The rules most teams in this space start with. Each one is a query against your own tables, adjusted to your schema during setup.
| rule | protects | runs |
|---|---|---|
| coupon-max-uses | Promotion budgets | 5 min |
| one-redemption-per-user | Coupon abuse | 5 min |
| stock-not-negative | Overselling | 1 min |
| order-total-consistent | Pricing bugs | 15 min |
| refunded-at-most-once | Double refunds | 5 min |
| no-payout-on-cancelled | Seller over-payouts | before each payout |
How it fits your stack
The agent runs next to your store database and reads orders, promotions and inventory directly. If your shop runs on a hosted platform, rules can run on the copy you sync into your own warehouse.
Campaign teams can see which promotions have rules on them, so a new code doesn’t go live without a limit check.
Common questions
We use a hosted e-commerce platform. Does this work?
Yes, if its data reaches a database you control, for example through an export or sync job.
Can rules run during a campaign spike?
Yes. Each rule has its own schedule, and the agent can run against a read replica so checkout isn’t affected.
Who writes the rules?
Invarly proposes rules from your schema. Your team approves, edits or writes their own.