Rippling Hotel Booking：第三方房态、搜索索引与预订一致性

题目重点：围绕外部酒店 API 的数据导入、地理搜索、可用房查询与确认预订，解释缓存展示与最终库存的边界。

题意与假设

这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。

训练版平台只做第三方酒店聚合：酒店/房型元数据可本地缓存，实时房态由酒店持有最终事实；题目没有说能否拿到 inventory change webhook，也没有房间 ID/时区/取消政策。
搜索位置按经纬度半径作为一轮明确追问，筛选入住/退房日期、人数与币种为酒店业务常见训练参数，不称其为题目确定输入。

接入层为各酒店维护 API adapter、外部 hotel/room/rate ID 映射、数据更新时间与可靠性指标；无 API 的酒店不能假设爬虫能稳定或合法取得可预订库存。
搜索分两步：本地地理索引召回半径内酒店及可选筛选，然后从候选酒店取得所需日期的房态/报价；本地陈旧缓存可帮助快速初筛，但 UI 必须说明价格和房态以最终确认结果为准。
预订状态机：创建幂等 request_id→酒店实时 availability/price quote→酒店 hold 或 confirm→本地记录外部 confirmation_id→支付/最终确认。若第三方不支持 hold，报价和预订间存在竞争，需接受售罄并给替代方案。
第三方调用超时后不能盲目重试成双订：先按外部幂等键或 request_id 查询状态；没有幂等 API 时本地标 `unknown` 并对账/人工处理。取消、部分失败和付款补偿要走独立状态转移。
数据表/索引按访问路径拆：Hotel(geo,metadata)、RoomType(hotel_id,capacity)、Offer(hotel_id,room_type,date,version/expiry)、Booking(user,external_ref,status,idempotency_key)；外部房态不因本地缓存存在就变成强一致。

两位平台用户同时看到酒店 H 的最后一间房：两人本地搜索都命中，但第一人先从酒店 API 成功 confirm，第二人 confirm 返回 sold_out。平台不能凭本地标记向第二人承诺成功；要刷新报价、释放任何本地支付预留并返回替代选项。

本地酒店地理召回可用空间索引缩小候选数，但实时房态检查成本随候选酒店数×外部 API 延迟增长；并发 100 个候选通常需分批/超时预算，不可串行承诺低延迟。题目没有酒店数、QPS 或 API SLA，不能填固定节点数。