Problem Statement & Context
What we are building and why dynamic pricing matters
Problem Statement & Context
A dynamic pricing engine computes the price a shopper sees at the moment of browsing or checkout. It is not a static catalog field — it is a decisioning system that blends business rules, demand signals, inventory constraints, and competitive intelligence to produce a price that optimizes revenue while protecting customer trust.
Pricing is touched by merchandising, supply chain, growth, and finance — so the engine is a high-trust service with strong audit requirements and predictable performance under load.
The journeys
- Shopper: open product → request price → engine fetches features + computes a decision → render + short-cache → add to cart (price lock) → checkout confirms the locked price.
- Merchandiser: define policies + guardrails → launch a promo/experiment → monitor margin + conversion → roll back.
- Pricing ops: ingest competitor + inventory feeds → validate model health/drift → approve high-impact changes → review audit.
The load-bearing idea: bounded optimization under hard guardrails, cached then locked
Two ideas anchor the design. First, pricing is bounded optimization under safety guardrails — an ML/optimization layer proposes a price to maximize revenue, but guardrails (min margin, max daily swing, floor/ceiling) clamp every decision so the system can never produce a harmful or illegal price. Rules for safety, ML for optimization, guardrails as the hard boundary. Second, the read/write split is an AP-browse / CP-checkout split: browse prices are served from cache and may be eventually consistent (fast), but a price lock freezes the price at add-to-cart so checkout is strongly consistent and the shopper is never surprised by a different total. Everything else — the cache, the audit log, the fallback chain — serves these two ideas.
Scale anchors
50M daily shoppers; 150M price evaluations/day; 20M SKUs with regional variants; 5× promo peaks. These drive the cache, the feature store, and the compute tier.
Key Highlights
- •A dynamic pricing engine computes the price a shopper sees at browse/checkout — NOT a static catalog field but a DECISIONING system blending rules + demand signals + inventory + competitive intel to optimize revenue while PROTECTING customer trust; a high-trust service with strong audit + predictable performance
- •Journeys: shopper (request price -> compute decision -> short-cache -> add to cart price lock -> checkout confirms the locked price), merchandiser (define policies + guardrails -> promo/experiment -> monitor margin/conversion -> rollback), pricing ops (ingest competitor/inventory feeds -> validate model drift -> approve high-impact -> audit)
- •Anchor 1: pricing is BOUNDED OPTIMIZATION under safety guardrails — an ML/optimization layer proposes a price, but guardrails (min margin, max daily swing, floor/ceiling) clamp every decision so it can never produce a harmful/illegal price (rules for safety, ML for optimization, guardrails as the hard boundary)
- •Anchor 2: an AP-browse / CP-checkout split — browse prices cached + eventually consistent (fast), but a PRICE LOCK freezes the price at add-to-cart so checkout is strongly consistent + the shopper is never surprised; everything else (cache, audit, fallback) serves these two; anchors 50M shoppers, 150M evaluations/day, 20M SKUs, 5× peaks
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "I will start with the base price and apply controlled adjustments."
- "We keep price decisions auditable and reversible."