Design a Global Hotel Search Availability & Pricing Cache Engine
You are the principal architect for a global online travel aggregator. The platform handles massive search volumes from users looking for hotel rooms across millions of properties. Backend queries to partner hotel inventory systems and dynamic pricing engines are extremely slow (2 to 5 seconds per request) and expensive, costing real money per API call.
Your task is to design a high-performance, read-heavy multi-tiered caching platform that serves hotel search queries with sub-20ms latency globally while maintaining strict room availability and price accuracy. The design must handle aggressive read traffic spikes on hot destinations without overwhelming supplier backends or crashing under cache stampedes when hot keys expire or undergo bulk invalidation.
- Serve search queries (destination, date range, guest count, and filter criteria) returning room availability and calculated pricing.
- Ingest high-throughput real-time updates from supplier inventory feeds and dynamic pricing engines.
- Provide deterministic cache lookup, tag-based invalidation, and granular property availability revalidation.
- Support graceful fallback to bounded stale data when supplier endpoints are degraded or unreachable.
- Read Latency: p99 < 20ms globally across all search endpoints.
- Read Volume & Scale: Baseline 500,000 QPS, bursting to 2,000,000 QPS during peak events.
- Freshness SLA: Supplier price and availability updates must propagate to all regional caches in <= 5 seconds.
- Availability: 99.99% read uptime, absorbing origin downtime seamlessly.
50 million hotel properties indexed globally. 10,000 supplier price/inventory update events per second. Average payload size per cached result page: 50 KB. Peak network egress across edge and cache layers exceeds 800 Gbps.
- High-level architecture diagram detailing Edge CDN, regional L1/L2 cache layers, invalidation message pipeline, and origin proxy backends.
- Cache data modeling and key indexing strategy for multi-dimensional query parameters (destination, stay dates, guest occupancy).
- Detailed invalidation workflow and cross-region propagation mechanism handling 10,000 updates/sec.
- Concrete cache stampede and thundering herd mitigation design for hyper-popular search keys.
Evaluates the design of the multi-level cache hierarchy (Edge CDN, L1 local/in-memory instance cache, L2 distributed cluster such as Redis/Memcached) across regions. Strong answers define precise caching boundaries, TTLs per tier, read-through/aside strategies, and how global traffic is routed to minimize latency and bandwidth costs.
Evaluates how high-cardinality combinatorial queries (city, check-in, check-out, guests) are represented in cache. Strong answers avoid key-space explosion by decoupling destination search indices from date/property availability grids (e.g., bitsets or compressed matrix objects), composing final response payloads dynamically at the cache tier.
Evaluates explicit prevention mechanisms against thundering herd problems when popular keys expire or get invalidated. Strong answers detail single-flight request coalescing (e.g., mutex/lock-free collapsing), probabilistic early expiration (XFetch algorithm), or lock-free stale-while-revalidate background fetches.
Evaluates how 10,000 updates/sec are fanned out to regional caches within 5 seconds. Strong solutions detail event-driven CDC/pub-sub pipelines (e.g., Kafka with geo-replication), fine-grained tag/version-based invalidation instead of cache flushes, and out-of-order update handling using monotonic version vector tokens.
Evaluates system safety mechanisms under severe supplier degradation or unexpected cache hit drops. Strong answers specify origin concurrency limiters, token bucket rate limiters per supplier, circuit breakers, serving stale availability marked with confidence intervals, and load-shedding strategies.
Every functional requirement in the brief is visibly served by something on the board, and the non-functional targets are addressed rather than ignored.
Components are labelled, data flows are drawn as connections between them, and the direction of each flow is unambiguous.
Follow-up: Suppose a major sporting event in Tokyo causes a 50x query spike for Tokyo hotel searches, while suppliers simultaneously push rapid price updates every few seconds for those exact properties. How does your cache layer prevent invalidation storms, maintain sub-20ms reads, and ensure supplier APIs do not collapse under backend load?
Global distribution across 3 major regions (NA, EU, APAC). Peak read volume: 2,000,000 QPS. Maximum allowed origin supplier API calls: 5,000 QPS globally. Read latency p99 < 20ms. Inventory and price freshness SLA: updates must reflect in caches globally within 5 seconds. Zero reliance on backend origin calls during cache revalidation for hot keys.
- Views
- 10