Design a Dynamic Pricing Engine — System Design Interview Practice

Interview prompt

Design an ML-driven dynamic pricing engine that updates prices from demand, competition, inventory, cost, and policy signals while protecting margin, fairness, and price stability.

• Separate authoritative catalog, cost, inventory, and pricing policy from model predictions, experiments, and cached offers.
• Version features and models, cap exploration, smooth price changes, and enforce floors, ceilings, currencies, and regional rules.
• Publish a price decision with reason, model version, and expiry so checkout can validate the quote and avoid stale surprises.
• Explain delayed competitor data, demand shocks, causal evaluation, rollback, fairness, auditability, and safe fallback pricing.

Requirements and scale assumptions

• Ingest sales, inventory, cost, competitor, promotion, and segment signals and calculate a versioned price recommendation.
• Serve current price and quote details, publish scheduled updates, run controlled experiments, and expose dashboards and explanations.
• Support price overrides, approval workflows, rollback, market-specific policy, stale-data handling, and audit history.
• Propagate material demand changes to eligible prices within five minutes and keep checkout quote validation below 100 ms.
• Price millions of SKU-market combinations with per-market partitions and isolated hot products or promotions.
• Make feature ingestion, model scoring, price publication, and experiment assignment idempotent and explainable.
• Fall back to the last approved rule-based price when models, competitor feeds, or inventory signals are stale.
• Support 10 million SKU-market series, 100,000 price reads per second, and frequent promotion bursts.
• Partition by market, SKU, and time; isolate hot products and prevent one competitor feed from blocking all updates.
• Retain signed price decisions, features, model versions, policies, and overrides while bounding live price caches.

• Peak scale: Provide pricing dashboards — Capacity assumption that drives partitioning and backpressure.
• Latency target: Price updates within 5 minutes of demand changes — User-facing budget for the primary request or read path.
• Durable boundary: Committed before async — The source of truth is Predict demand elasticity per product; Monitor competitor prices in real-time.
• Async boundary: At-least-once workers — Keep Use price elasticity models (log-linear demand curves), Implement contextual bandits for exploration vs exploitation, Use causal inference to estimate price sensitivity off the synchronous path.

Key entities

• DatasetVersiondatasetId, version, schemaHash, qualityStatus, lineage, createdAt

  Immutable dynamic pricing engine input version used for reproducible training, evaluation, or replay.

• FeatureSnapshotentityId, featureSetVersion, eventTime, values, sourceWatermarks

  Point-in-time dynamic pricing engine features with source watermarks so online and offline values can be compared.

• TrainingRunrunId, datasetVersion, codeVersion, metrics, artifactUri, status

  Audited dynamic pricing engine run that records data, code, dependency, and evaluation lineage.

• ModelVersionmodelId, version, stage, schema, qualityGates, endpoint

  A promotable dynamic pricing engine model version with rollout state, contract, and rollback metadata.

Data flow

1. 1. Register and validate training dataThe dynamic pricing engine gateway records an immutable dataset version, schema, lineage, quality status, and privacy disposition.
2. 2. Build point-in-time featuresFeature workers join dynamic pricing engine inputs using event-time watermarks, prevent leakage, and publish the same feature contract for training and serving.
3. 3. Train and evaluate asynchronouslyThe orchestrator schedules dynamic pricing engine runs with checkpointed artifacts, reproducible environments, and metrics tied to the exact input versions.
4. 4. Gate and serve a model versionA registry compares dynamic pricing engine quality, bias, safety, and compatibility gates before canary or production rollout with an immediate rollback pointer.
5. 5. Monitor drift and learn from feedbackOnline inference records latency, errors, drift, and delayed labels so dynamic pricing engine retraining is evidence-driven rather than triggered by guesswork.

Deep dives and trade-offs

• Reproducibility and leakage preventionPin dynamic pricing engine data, feature, code, dependency, and model versions for every run. Use point-in-time joins and quarantine failed quality or privacy checks before training. Keep raw inputs and artifacts immutable so a result can be replayed after a dependency changes.
• Safe promotion and serving contractsSeparate dynamic pricing engine model registration from deployment and require signed artifacts plus schema compatibility. Use shadow traffic, canaries, rollback pointers, and per-version latency/error budgets. Return model version and feature freshness so clients can explain or reproduce a prediction.
• Drift, feedback, and costMeasure feature drift, prediction drift, label delay, and segment-level quality for dynamic pricing engine rather than only aggregate accuracy. Sample expensive inference and cap retraining concurrency with an explicit GPU or compute budget. Keep human corrections and delayed labels linked to the original prediction and model version.
• Batch versus online featuresPrefer a shared feature contract with batch backfills and a low-latency online serving path for decisions that need freshness. Two independently defined transformations create training-serving skew and hard-to-debug regressions.
• Synchronous versus asynchronous inferenceKeep interactive dynamic pricing engine inference synchronous within a strict budget and queue large or expensive jobs. A request path that waits for model loading, enrichment, or retraining turns downstream slowness into an outage.
• Global model versus segment modelsStart with one versioned model and add segment-specific models only when quality or policy evidence justifies the operational cost. Many simultaneously active versions multiply monitoring, rollback, and data-lineage burden.