A sub-100ms personalised surge-pricing engine for a US food marketplace

Challenge

Prices were a table edited by hand. Demand spikes went unpriced, loyal customers paid the same as first-timers, and every pricing tweak was a deploy of the whole monolith. The product team wanted dynamic, personalised pricing that still felt fair, and engineering wanted to stop deploying everything to change one number.

Approach

Make pricing a service with a budget

The quote endpoint got a hard budget: 100 ms p95, including all signal lookups. That single constraint shaped everything else.

• Availability comes from an in-memory view fed by inventory events, refreshed asynchronously; the quote path never queries inventory directly.
• Spend history is a pre-aggregated per-user profile in Redis, updated by an order-events consumer.
• Geolocation maps to a pricing zone with a cheap geohash lookup.
• The engine combines the three with a rules layer product can tune without a deploy, plus guardrails (caps and floors) so personalisation never looks like discrimination.

Pull it out of the monolith

Pricing, ordering and notifications became event-driven microservices communicating asynchronously. Each service owns its data and consumes the events it needs; the quote service has no synchronous dependency on the order service. Independent deployability was the point: pricing could ship daily while ordering stayed stable.

Working across time zones

I was in India; the team was in Seattle. Sprint planning, code review and incremental rollouts (feature flags, percentage ramps, dashboards for the on-call engineer in their morning) kept it safe. Written design notes before each change replaced the meetings we couldn't have.

Architecture

What shipped

• A quote API meeting the 100 ms budget at p95.
• Event-driven order, pricing and notification services with their own pipelines.
• A rules console so product could change pricing logic safely.

Results

• Personalised pricing live with <100 ms quotes.
• Pricing changes decoupled from monolith releases.
• The same decomposition approach later informed the InkHub re-architecture that cut cloud spend by 76%.

What I'd do differently

• Shadow-price for a few weeks before switching: log what the engine would have charged next to what it did, then compare margins. We did it for one week; it deserved three.
• Treat the rules layer as code with tests from the start; "editable without a deploy" also means "breakable without a review" unless you add guardrails, which we did, later.