Prices change continuously based on demand and dates. Search must filter and sort by price over millions of listings. How?

What the interviewer is testing

Whether you recognise the combinatorial explosion in the naive design and can find the reduction.

Why the naive designs fail

Compute prices at query time. A search for a date range across a region needs the price for each candidate property for those dates. Running a pricing model per property per query, over millions of listings, at search volume, is not feasible within a search latency budget.

Precompute every combination. Price depends on property, check-in date, length of stay, guest count and occupancy. That is a combinatorial space far too large to materialise — millions of properties times hundreds of start dates times stay lengths.

The design

Precompute a bounded slice. For each property, compute a nightly price for each date over the booking horizon — one value per property per night, which is a large but tractable number. Most of the search need is served by aggregating those nightly values.

Index approximate prices for filtering and ranking. The search index carries a nightly price or a small set of typical totals, which is sufficient to filter a price range and to rank. Search does not need the exact figure; it needs a good enough ordering and a correct filter.

Compute the exact price on the listing page and at booking, where the volume is orders of magnitude lower and full model evaluation is affordable.

Recompute incrementally. When demand signals change for a property or a region, refresh those nightly values rather than the whole index. Pricing changes are localised, so the update volume is far smaller than the total.

The consequence to design for

Search prices and final prices can differ. That must be handled honestly in the product — showing an indicative price and being explicit about what is included — and it has consumer protection implications in several jurisdictions, so the tolerance is a legal question as well as a technical one.

What a strong answer adds

Framing it as the general trade: precomputation cost versus query cost versus staleness. Every search system with dynamic attributes makes this choice, and the reduction is nearly always to precompute along the dimension with bounded cardinality (nights) rather than the combinatorial one (stays).

Common weak answers

Caching query results, which does not help when queries have high cardinality across dates and regions. Precomputing every stay combination.