The Flash Sale That Broke the Catalog
A mid-market apparel retailer runs a 4-hour flash sale every Friday at 12:00. On the most recent Friday, the merchandising team published a catalog price rule that discounted 1,200 SKUs by 30%, stacked on top of an already-active 10% customer-group discount for logged-in members. Within 8 minutes, the storefront slowed to 20+ second page loads, the checkout queue backed up, and support received 40 complaints that prices in the cart did not match the product page. The rule was built with no conditions beyond the discount amount and was set to apply to the entire catalog. The site runs in a single-website, single-store-view configuration with a shared catalog. The merchant asks you how to prevent this next week without canceling the sale.
1. Diagnose why the cart prices diverged from product-page prices and why the site degraded, and propose the configuration changes you would make before next Friday.
Read the worked answer
Two separate problems are interacting.
Price divergence. When multiple promotions can apply, the storefront product page and the cart can resolve them at different moments in the request lifecycle. A catalog rule with no conditions and a full-catalog scope forces a re-index of price data across ~1,200+ SKUs, and if the indexer is running in 'Update by Schedule' mode, the catalog-side prices lag behind the cart-side rule application. The customer sees a stale product-page price and a freshly-computed cart price. The fix is not 'remove the discount' - it is to make the rule deterministic and to control indexing.
Degradation. A conditionless rule applied to the whole catalog means the price indexer must evaluate every product, and every product-page and cart request re-evaluates applicable rules. Combined with a stacked customer-group discount, the number of price permutations the index has to store grows, which is exactly the kind of thing that turns an 8-minute window into a 20-second page load.
Concrete changes:
- Scope the catalog rule with an attribute set / SKU condition so it touches only the 1,200 intended SKUs, not the full catalog.
- Decide the stacking policy explicitly. If the intent is 'members get 30%, not 40%,' set the rule's stop-further-rules behavior so the group discount does not compound. Document the decision - this is a business call, not a technical one.
- Switch price and catalog-rule indexers to 'Update by Schedule' and run a manual reindex before 12:00, then confirm the indexer backlog is zero. Do not publish rules at 11:59.
- Test in a staging environment with the same rule set and confirm cart and product page agree for a sample of SKUs across categories.
- Consider a scheduled rule with explicit from/to dates rather than a manual publish at sale time, so the index is warm before the window opens.
2. The merchant says 'just turn off the customer-group discount during the sale.' What is the business risk, and how would you frame the trade-off back to them?
Read the worked answer
Turning off the group discount changes the deal members were promised and can read as a bait-and-switch if the 10% was advertised as a standing member benefit. The framing to give the merchant is a choice among three explicit policies:
- Stack (members get 40%): highest margin hit, but the cleanest customer message and the least support load. Only viable if the 1,200 SKUs' margin supports it.
- Cap (members get 30%, the better of the two): protects margin and is defensible if you communicate 'members already get the best price.' Requires the rule's stop-processing setting so it does not compound.
- Exclude (members get 10% only on these SKUs): worst customer experience and the most likely to generate complaints; avoid unless the SKUs are loss-leaders.
The exam-relevant point: the practitioner's job is to surface the margin and customer-experience consequences of each option and get a written decision, not to silently pick one. The support complaints in the setup are a symptom of an undocumented stacking decision, not of the discount itself.