Design a travel application backend

Problem Design the backend of a travel application: users browse destinations, search for options (stays/flights), view details and prices, and make bookings.

Functional requirements

• Search destinations and inventory with filters (dates, price, location).
• View listing details with up-to-date pricing and availability.
• Create a booking with payment, confirm it, and view booking history.

Non-functional requirements

• Read-heavy: ~100x more searches than bookings; search p99 under ~500 ms.
• Bookings must be consistent — no double-booking the same room/seat; payments exactly-once.
• Target scale to discuss: ~10M DAU, ~1K search QPS, ~50 bookings/sec peak.

Key components

• API gateway → search service (backed by an inverted index / Elasticsearch, cache for hot destinations), inventory service (source of truth, relational DB), booking service (orchestrates hold → payment → confirm), payment integration, notification service.
• CDN + cache for static content and popular search results.

Deep dives / trade-offs

• Double-booking prevention: row-level locking vs optimistic version checks vs short-TTL reservation holds.
• Cache invalidation when prices/availability change; how stale a search result may be vs the authoritative check at booking time.
• Booking as a saga: compensating actions when payment fails after inventory is held.