Retail & eCommerce

Almost always because two systems each believe they own it. The fix is making one the source and every other a reader of it, then reconciling on a schedule so drift raises an alert instead of producing a cancelled order. Where a marketplace or third-party warehouse holds its own count, the rule for who wins has to be explicit rather than assumed.

That is the normal shape of this work. The site, the point of sale and the warehouse each need to see the same stock and the same order, and the integration layer belongs in one place so replacing any of the three later is contained. Most of the value shows up in orders that no longer need typing twice.

Only if it is tested against your own peak rather than an average day. We load test from your own history, fix what fails before the season, and decide in advance what is allowed to degrade: a slightly stale stock figure, a queued email, so that behaviour under load is a decision rather than a surprise.

Not usually. Most of what makes an online shop work badly is the joins between systems rather than the shop itself, and replacing the platform without fixing those simply moves the problem. If the platform genuinely is the constraint, that case should be made with evidence from your own data.

By early summer for anything structural, and that is not a sales line. Load testing is only useful if there is time to act on what it finds, and what it finds is rarely small: a query that is fine at a hundred orders an hour and not at a thousand, a third-party tag adding a second to every page, a stock check that calls an external system on every basket view. Each fix then has to be released, watched and left alone for a few weeks before the traffic arrives. Work that starts in October is limited to configuration, caching and turning things off, which is a legitimate way to survive a season but is not the same as being ready for one.

Yes, and deciding what in advance is the entire point of having one. Content, prices, promotions, banners and category changes have to remain possible during trading, because merchandising cannot stop for two months and will find a way round a rule that says it must. Code is different. A release in peak week has no comfortable window to correct itself in, so what ships during a freeze is limited to defects with a real commercial cost, goes out behind a switch that can be turned off without a deployment, and has a named person watching it afterwards. The freeze that fails is the one nobody agreed with the trading team, because they will simply ask a developer directly.

Usually yes, with a buffer, and the size of that buffer is a commercial decision rather than a technical default. Marketplaces punish cancellations harder than your own site does, since a late dispatch or an order you cannot fulfil affects your seller metrics and eventually your visibility, so the last few units are the ones worth protecting. Shared pools also need a sync fast enough to matter, because a stock update that takes twenty minutes during a sale is simply a queue of oversells waiting to happen. Where a marketplace holds its own fulfilment stock, treat that as a separate location with its own count rather than as part of the main pool, and reconcile it on the same schedule as everything else.

Against the original order, with the customer, support and finance all reading the same record. What goes wrong is the middle rather than either end: the goods are in transit, the refund has been promised, the payment provider has not settled it, support cannot see any of that, and the customer rings twice and gets two different answers. So a return gets its own states, each of them visible, and the refund records what was actually paid back rather than what was expected to be. Decide the policy questions first, including who pays return postage and what happens when an item comes back unfit to resell, because the software cannot make those decisions for you and will expose them either way.