A lodging marketplace must show accurate availability across search, listing pages and booking. Which of these need strong consistency?

What the interviewer is testing

Whether you can decompose a system by consistency requirement rather than applying one model throughout.

The reasoning

Ask what each failure costs.

Search results slightly stale. A user sees a property in results that was booked forty seconds ago. Cost: a mild disappointment on the next click. Search is also the highest-volume, most latency-sensitive path — forcing it to strongly consistent reads would be ruinous, and it is a fan-out over many properties, so the staleness cost is spread across many results of which most are still available.

Listing page slightly stale. Same cost, lower volume, and here it is worth being slightly fresher because the user has expressed intent.

Booking commit. A double booking is unrecoverable in the way the others are not: two guests hold the same room on the same night, and resolving it means cancelling someone, compensation, reputational damage and possibly regulatory exposure. This has a global invariant and must be strongly consistent.

So consistency effort concentrates on the smallest, lowest-volume, highest-consequence step.

The mechanism at the commit

A conditional write — an atomic operation that succeeds only if the dates are still free, enforced by the database rather than by application logic. A read-then-write with a check in application code is a race, and at marketplace concurrency it will lose.

Frequently paired with a hold: the dates are reserved for a bounded period while payment is processed, and the reservation expires if the booking is not completed. That way the irreversible commitment happens once, after everything else has succeeded.

What a strong answer adds

Managing the user experience of the gap. If search can show an unavailable property, the booking failure must be handled gracefully — explaining what happened and offering alternatives immediately, rather than returning an error at the end of a checkout flow.

And a freshness gradient: the closer the user is to committing, the fresher the data. Search from a lagging index, listing page from a fresher read, availability calendar checked live, booking against the authoritative store.

Common weak answers

Strong consistency everywhere, which does not scale for search. Eventual consistency at the booking commit, which oversells.