Why a Real‑Time/Offline Price Cache Is Critical for High‑Traffic Hotel Booking

Overview: Need for a Quote Cache

Hotel quote APIs require millisecond‑level response times, but many third‑party agents respond slowly, creating a performance bottleneck. High query peaks exceed agents' rate limits, and unnecessary data processing inflates computational load. A cache layer is therefore essential to meet latency, stability, and user‑experience requirements.

Core Architecture: Real‑Time and Offline Separation

The solution splits the workflow into a real‑time calculation link and an offline query link. The real‑time service reads cached data and performs lightweight processing to guarantee millisecond responses. The offline system asynchronously contacts agents, aggregates their quotes into hotel‑level data, and writes the result back to the cache.

Key Mechanisms

Bidirectional update driven by user traffic (searches) and order events, triggering cache refresh when needed.

Cache‑freshness decision based on four timestamps: cacheTime (expiration), sentTime (request sent), receiveTime (response received), and storeTime (stored in cache).

Peak‑shaving query logic that intercepts many user requests, only querying agents when the cached quote is stale or when special conditions (offline, out‑of‑service, etc.) apply.

Price‑change driven updates: after a price‑change notification, the system refreshes the most recent dates rather than the exact change date, and uses a price‑change interval mapping to force queries when the user’s stay period overlaps a known change window.

Data Safety and High Availability

Hotel‑level quotes have an expiration time (typically check‑in date + 1 day 6 am) while agent‑level quotes are kept indefinitely to allow fallback to previous data. Redis is used with master‑slave double‑write; if the primary fails, the standby takes over. Large hotels with many agents store quotes in sharded keys to keep query latency low.

Results and Metrics

Cache hit rate reaches 97%; only 3% of queries miss, most of which are due to missing agent data.

During traffic spikes (e.g., National Day), user query volume rose sharply but the rate of queries sent to agents fell, demonstrating effective peak‑shaving.

Overall, real‑time queries to agents were reduced by roughly half while maintaining accurate pricing.

Frontend Collaboration

The front end receives a “freshness” flag for each hotel quote. If the cache is stale, the UI can trigger a secondary request. A periodic refresh timer also re‑queries quotes for users who stay on the page for a long time, preventing outdated prices from being displayed.

Summary and Outlook

The cache architecture decouples heavy data preparation from the critical request path, ensures data accuracy through dual‑driven updates, and builds resilience with master‑slave Redis and sharding. Future work includes turning the standby Redis into a hot‑standby with regular failover drills and defining a proactive SOP for forced cache refreshes to further improve reliability.