Dynamic pricing

01 · CONTEXT

What a dynamic pricing engine is

The public description of the dynamic pricing challenge in the Educative course sums up the problem like this: adjust product prices in real time, based on user context, market conditions, and observed demand. In general terms, a dynamic pricing strategy sets flexible prices according to current market demand.

These prices usually come from algorithms that take into account competitor prices, supply and demand, and other external market factors. The simplest way to price, cost plus a fixed margin, uses only internal information and does not account for market reaction.

02 · ELASTICITY

How much demand reacts to price

Price elasticity of demand measures how sensitive the quantity demanded is to price. It expresses the percentage change in quantity when the price rises, holding everything else constant.

The time horizon matters: for most goods, the longer a price change lasts, the greater the elasticity tends to be.

For a pricing engine, the design question is where the elasticity estimate will come from and how often it is re-evaluated. An estimate is always a hypothesis about the data the system has already seen.

03 · BANDITS AND FEEDBACK

Exploring prices without losing revenue

The multi-armed bandit problem is a classic reinforcement learning problem that exemplifies the dilemma between exploration and exploitation. At each attempt, the choice is between exploiting the option with the highest expected return and exploring to gain more information about the others.

Applied to pricing, each candidate price band plays the role of an arm: testing a new band generates information, but may cost sales. The boundary between testing and exploiting is a design decision in the context of ML system design, not an algorithm detail.

One possible design, shown below, separates the price lookup path from the learning path, an idea common in real-time analytics. The pricing service responds quickly using already prepared signals, and the decisions and sales results flow asynchronously to update those signals.

1. The client requests a product's price from the gateway, which forwards the request to the pricing service.

2. The pricing service reads that product's recent demand signals from the cache, to respond without waiting for the database.

3. The service picks a price: most of the time it exploits the best known band and, in some cases, explores a new band.

4. The decision and the sale result are published to the queue, without delaying the response to the client.

5. The updater consumes the events, writes the history to the database, and refreshes the signals in the cache. This is where the chosen price comes back to influence the following data.

04 · OPERATION AND LIMITS

Observability and business rules

An engine that changes prices on its own needs monitoramento: tracking the prices charged, the sales observed, and the behavior of the algorithm itself, with alerts when something goes out of the expected range.

It also makes sense to limit what the algorithm can do, with a minimum and maximum price per product and a way to turn off exploration. These limits are business rules and do not depend on the algorithm.