Design a Pricing Optimization Analytics

Problem statement

Design a pricing optimization analytics platform that continuously collects competitor price data, inventory levels, and demand signals, then runs rules and ML models to suggest or set product prices either on a schedule or in near real-time. The system is not a dashboard; it is a closed control loop with four stages: sense (competitor offers, clickstream, inventory, costs), decide (elasticity models, rule engines, guardrails), act (publish prices to storefronts, marketplaces, and POS), and measure (exposure, conversion, margin, experiment readouts). Every stage has a different latency, consistency, and failure profile, and a strong answer separates them explicitly.

Why this is a distinctive big-data problem: the write path is dominated by high-rate external observations (competitor scrapes, marketplace feeds, clickstream) while the correctness-critical path is the price decision ledger, which must be auditable, versioned, and reversible. A stale competitor observation should degrade gracefully; a wrong published price is revenue loss, brand damage, or a compliance violation. The design therefore treats observations as eventual, timestamped, TTL-bound data, and treats published prices as strongly consistent per-SKU state with optimistic versioning and an append-only decision log.

Public operating baseline versus design assumptions

Public evidence shows the category is operationally real at extreme scale. Third-party marketplace analyses repeatedly report that Amazon changes prices about 2.5 million times per day, with an average product repriced roughly every 10 minutes. Walmart Global Tech describes Element, an ML platform whose core is a product matcher used for competitive price determination. Airbnb's engineering blog describes learning market dynamics for Smart Pricing and price tips. Uber built H3, an open-source hexagonal spatial index used for surge pricing and dispatch, with resolution 8 commonly cited for surge cells. Airlines file fares through ATPCO and are moving toward continuous pricing and dynamic offers. These are cited public claims; they motivate the design but are not requirements for our fictional system.

For capacity planning this answer explicitly assumes a mature marketplace with 100 million active SKUs, a hot set of 5 million reprice-eligible SKUs, 10 competitor feeds producing 50 million price events per day, and 2 billion demand events per day. Unless a number is tied to a citation, it is a stated design assumption, target, or budget.

The four architectural planes

1. Sensing plane: competitor ingestion, catalog and inventory sync, clickstream capture, cost and promotion feeds.
2. Analytics plane: feature store, elasticity and competitor-gap models, rule engine, batch and stream decision pipelines.
3. Action plane: guardrail validation, price publication, storefront cache invalidation, marketplace feed emission.
4. Governance plane: experiment readout, revenue impact monitoring, compliance rules, audit, kill switches, rollback.

A strong interview answer keeps these planes separate so the analytics plane can degrade without weakening guardrails, and so governance can freeze or roll back prices without redeploying models.