Design Expedia.com

Problem Open-ended: design Expedia.com — a travel booking site covering search, pricing, and booking across hotels/flights/cars.

Functional requirements

• Destination/inventory search with filters and pricing; listing detail pages; booking with payment; user accounts with trip history; scope with the interviewer (start with hotels only).

Non-functional requirements

• Read-heavy (search:booking well over 100:1); search p99 < 500 ms; no double-booking; scale to discuss: tens of millions of users, thousands of search QPS, spikes in holiday season.

Key components

• Edge/CDN + API gateway; search service over an inverted/geo index with heavy caching; pricing/availability service (rates change often — cache with TTL + authoritative recheck at checkout); booking service (hold → pay → confirm state machine, transactional store); payment integration; supplier/GDS connectors syncing external inventory; notification service; user/trips service.

Deep dives / trade-offs

• Inventory freshness vs search speed: stale-tolerant search results with a strict availability check at booking time.
• Double-booking prevention: reservation holds with TTL, idempotency keys on the booking API, saga/compensation when payment fails.
• Caching strategy per layer (search results, detail pages, price quotes) and invalidation on supplier updates; database partitioning by property/region for scale.