AI Dynamic Pricing Engine

Repricing a Large Catalog from Demand, Stock and Rules

Design the engine that sets prices for millions of products from estimated demand, stock, deadlines and competitor prices, inside guardrails that keep every price legal, explainable and stable.

Overview

A dynamic pricing engine changes prices over time instead of fixing them once. It exists because the best price moves: demand rises and falls with season, day and events; stock runs down; competitors change their prices; and some goods (a seat on a flight, a hotel night, a winter coat in March) lose their value after a date.

The engine answers one question for every product, again and again: given what we believe about demand, what price earns the most while staying inside the rules? The belief is the hard part. Revenue is price times units sold, and units sold depend on price in a way the engine can only estimate, from data that its own earlier prices shaped.

It also has to be safe. A pricing loop with no sanity check can run away: in 2011 a biologist watched two Amazon marketplace sellers reprice a textbook off each other every day until it was listed at $23,698,655.93. Laws limit price increases in declared emergencies (California caps many at 10%), and US antitrust enforcers have sued over pricing software fed with competitors' private data. The design treats guardrails as part of the engine, not an afterthought.

Questions to ask first

What is being priced? — 10 million products in an online store; some seasonal, with stock that must sell by a date
What is the goal? — Profit over the season, subject to rules; not revenue alone
How often can prices change? — Fast movers every 15 minutes, the rest once a day
May two shoppers see different prices at the same moment? — No: one price per product per region at a time
Who can override the engine? — Pricing managers, per product or category, with an expiry
What must be kept? — Every published price, why it was chosen, and who or what set it

What you will be able to do

Write down the pricing objective and find the best price under a floor, a ceiling and a step limit.
Explain why historical sales give the wrong price sensitivity, and how experiments fix it.
Price stock that must sell by a deadline with a small dynamic program.
Design guardrails that stop runaway loops and keep prices legal.
Serve one consistent, versioned price to product pages and carts at 50,000 reads a second.

Key concepts

Price elasticity
Demand model
Confounding
Price experiments
Thompson sampling
Perishable inventory
Guardrails
Price versions
Audit log

Functional requirements

Estimate demand and price sensitivity per product, from sales, views, stock, season and competitor prices
Choose a price per product and region on its schedule (every 15 minutes or daily)
Account for stock and selling deadlines on seasonal and perishable items
Run price experiments without showing two shoppers different prices at the same time
Enforce floors, ceilings, step limits, legal caps and manual overrides before publishing
Serve the current price to pages and honor it in the cart for a fixed time
Record every published price with its inputs, model version and reason

Non-functional requirements

Price reads under 10 ms at p99 from cache (a target we chose)
A price shown in the cart is honored for 30 minutes (a rule we chose)
No published price outside its product's floor, ceiling and step limit, ever
A bad model or feed can be stopped in one switch, falling back to the last good prices
Price history kept for audit for as long as the legal team requires

Interview questions

How do you choose the price for one product?
Why can't you estimate elasticity from historical sales?
How do you run price experiments without treating shoppers unfairly?
How do you price seats or stock that must sell by a date?
What stops the engine from doing something absurd?
How do you serve prices at 50,000 reads a second and keep checkout consistent?
Can you use competitors' prices?