Here is solutions for Design Booking System - Follow-up questions.

Main topic:

• Read-write seperate: elastic search for read, booking for write.

• Data-model design: design each product code -> to a record -> same product type only: book.

• Concurrency Booking: optimistic (show availability, handle failures) or pessimistic (real-time checks, slower UX) or distributed lock - when customer starts checkout, immediately reserve with seller API for 5-10 minutes

• Downtime of Payment System: handle downtime of payment system -> using Kafka + Temporal (State Machine) for retry and reverted.

Book Seller System:

Hotel Booking System:

1. Patterns for Design Booking System

1. Using Elasticsearch for read-heavy: fed by CDC for search isolates OLTP from read-heavy geospatial/text queries and keeps search latency low while scaling independently.

2. Sharding the SQL database by hotel_id: localizes booking transactions and inventory updates to a shard.

3. State-machine - Temporal: Idempotency keys, a booking state machine, and event-driven updates via Kafka show good operational hygiene and support safe retries and downstream notifications.

4. The lock should be: hotel_id + day range (D1, D2, D3) that they book.

5. Persimistic Locking: High-concurrency booking

SELECT * FROM tasks WHERE status = 'pending' LIMIT 1 FOR UPDATE SKIP LOCKED;

- Worker 1 runs: SELECT * FROM tasks WHERE status = 'pending' LIMIT 1 FOR UPDATE -> It grabs and locks Task #1.

- Worker 2 runs the same query -> It sees Task #1 is locked. Instead of waiting, it skips Task #1 and instantly grabs Task #2.

1. Optimistic Locking: client need to retry multiple time -> can not use in high concurrency booking.

2. Different consistency level in third party data + booking data:

   • Stale data process quickly: 1 - 3 seconds.

   • Worker: webhook + async worker -> call to provier -> update ES.