The engine was working perfectly, which is the problem
Start by being precise about what failed, because the instinct is to look at the pricing service and there is nothing wrong with it. It received an instruction to set a price, it validated the payload, it published the change, and every downstream consumer propagated it promptly. Fast propagation made the incident worse: a slower pipeline would have given someone a chance to notice. The defect is that no component in the chain had any opinion about whether the instruction was plausible.
That is the framing an interviewer is listening for. Price is not a field, it is a commitment, and any system that accepts arbitrary values for it from an integration is one bad upstream deployment away from giving the catalogue away. The controls therefore belong on the change, and they have to exist inside your estate, because the thing that failed was outside it and you cannot fix somebody else's repricer.
Validate the change, not the payload
Schema validation passes a penny. Useful validation compares the incoming price to things you already know, and there are four comparisons worth having, each catching a different fault.
Relative to the previous price. A movement beyond some multiple or fraction of the current price is suspicious on its own. This is the cheapest and most effective bound, and it is also the one that will annoy the trading team, because genuine clearance markdowns are large. The resolution is not to widen the bound until it never fires; it is to require an explicit, attributed override for a change that exceeds it, so a real markdown of ninety per cent is possible and is somebody's decision.
Relative to cost. A price below the cost you hold for the item is either an error or a deliberate loss-leader, and the two should not look the same to the system. A floor derived from cost, with an authorised exception for the deliberate case, catches the entire class of mispricing that bounds relative to the previous price will miss when the previous price was already wrong.
Against an absolute floor. Very small non-zero amounts are almost never intentional and are worth refusing outright, separately from any relative test, because they are the signature of a unit or parsing fault rather than a commercial decision.
Against units and currency. The commonest silent corruption is a mismatch between minor and major units, where an integration sends a value in pence and the loader treats it as pounds or the reverse. That is wrong by two orders of magnitude and will pass every relative bound if it arrives on a brand-new item with no history. Typed money with an explicit currency and scale at the boundary, rather than a bare number, is what prevents it.
Bound the blast radius, not only the item
Per-item validation is necessary and insufficient, because the incident is defined by volume. Ten thousand items changed at once, and no individual change looks like an outage. What you need alongside the per-item bounds is a view of the batch as an object with a shape.
Concretely: a limit on how many prices one feed may move in a window, a proportion-of-catalogue threshold above which a change requires approval rather than proceeding, and a comparison of the batch's aggregate effect on average price or notional margin against what is normal for that feed. A repricer that has always adjusted a few hundred lines an hour and suddenly submits ten thousand at once has changed behaviour, and that alone is grounds to hold the batch pending a human. Holding is safe in a way that publishing is not: a delayed price change costs you a little trade, and a published one costs you the goods.
Two further habits belong here. Stage the rollout, so a large batch lands progressively and its effect is observable on a small share of traffic before it is universal. And keep a kill switch on automated repricing per feed — a single flag that stops accepting changes from that source without requiring a deployment, with the authority to pull it delegated to whoever is on call rather than reserved for someone reachable only in office hours. A control that needs a release to activate is not a control during an incident.
You will not be told, so instrument the symptom
Detection in this class of incident is usually accidental, which is why the exposure grows for hours. Yet the symptom is loud if you are watching the right series. Units ordered per SKU per minute against its own baseline spikes hard. Average order value collapses. Notional margin per order goes negative. The proportion of orders containing an item priced below cost goes from nothing to something. Any one of those, alerted on at the order stream rather than at the price stream, gives you minutes instead of hours, and the order stream is the right place to watch because it is where the loss actually occurs.
It is worth saying plainly that price-side monitoring alone would not have caught this, because the prices were published successfully and the pipeline was healthy throughout. Every dashboard was green.
Stop the parcels before you debate the money
The sequencing of the response is where candidates most often go wrong, because they reach for the commercial question first. The order of operations is: stop new orders from being priced wrongly, stop the affected orders from being dispatched, then decide.
Pulling the feed's kill switch and reverting the prices addresses the first. The second needs a fulfilment hold applied to the affected orders, and it is the step with a hard deadline attached, because an order that has been picked and manifested is gone. Whether you can place that hold quickly on a set of orders identified by a price predicate is a capability you either built or did not, and this incident is what it is for. Digital goods and instantly-delivered items have no such window at all, which is worth naming as a category where the only viable control is prevention.
Only then does the honour-or-cancel question arise, and the honest answer is that it is not yours to make alone. Whether a contract has been formed, and at what point in your flow, depends on the jurisdiction and on your own published terms, so it is a question for legal and trading with a playbook agreed in advance rather than drafted under pressure.
What engineering owes them is a fast, accurate exposure figure — how many orders, which customers, what value at correct prices versus penny prices, how many already dispatched — and a mechanism to act on whichever decision comes back, including a partial one that honours small-value orders and cancels the rest. Assume the outcome will be scrutinised publicly, and make sure whatever you do is applied consistently across every affected customer, because inconsistency is what turns a pricing error into a reputational story.
When the repricer, not the pricing engine, decides the price
In December 2014, a third-party repricing tool used by sellers on Amazon's UK marketplace malfunctioned and reset a large number of listings to a penny before the listings could be pulled, and orders were placed against those prices in the interval. The instructive part is that the pricing engine was working exactly as instructed by an upstream integration that was not; nobody had bounded what a price change was allowed to do. An interviewer will want to hear about sanity bounds, rate limits on bulk price movement, and a kill switch on automated repricing, rather than only about how fast prices can propagate.
Every price you publish is an offer you may have to stand behind, so the question is never how fast changes propagate but what a change is permitted to do. Bound it against the previous price and the cost, bound the batch by rate and share of catalogue, and make sure you can freeze dispatch faster than you can convene a meeting.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).