System requirements

Functional:

customer can search hotel room by type

customer can reserve hotel room

admin can create/update/delete room/hotel

Non-Functional:

system needs to be consistent, no double booking

system needs to be scalable

system needs to be highly available

do we allow certain percentage of over booking?

do we support hourly booking?

Capacity estimation

total hotels: 5000

total rooms: 5000 * 200 = 1M

70% booked, 3 days average,

1M * 0.7 / 3 = 230,000

230,000 / 100,000 = 2.3 < 3 TPS

3 / 10% / 10% = 300 QPS

API design

hotel:

GET /v1/hotels/{hotel_id}

POST /v1/hotels/

PUT /v1/hotels/{hotel_id}

DELETE /v1/hotels/{hotel_id}

room:

GET /v1/hotels/{hotel_id}/rooms/{room_id}

POST /v1/hotels/{hotel_id}/rooms

PUT /v1/hotels/{hotel_id}/rooms/{room_id}

DELETE /v1/hotels/{hotel_id}/rooms/{room_id}

room_type:

GET /v1/hotels/{hotel_id}/room_type/{room_type}

reservation:

GET /v1/reservations/{reservation_id}

GET /v1/reservations/

POST /v1/reservations/

DELETE /v1/reservations/{reservation_id}

payment:

POST /v1/payments/

Database design

hotel:

hotel_id: INT PK, city: VARCHAR(100), name: VARCHAR(50), addr: VARCHAR(255)

room:

room_id: INT PK, room_number: VARCHAR(10), hotel_id: INT, room_type_id: INT, status: ENUM

reservation:

reservation_id: BIGINT, hotel_id: INT, room_type_id: INT, start_date: DATE, end_date: DATE, total_amount: VARCHAR(20), status: ENUM, guest_id: BIGINT

inventory:

hotel_id:INT, room_type_id: INT, date: DATE,

total_rooms: INT, remaining_rooms: INT

rate:

hotel_id:INT, room_type_id: INT, date: DATE, price: VARCHAR(20),

High-level design

customer client -> CDN, API gateway -> reservation service -> reservation db, inventory db

customer client-> CDN, API gateway -> hotel service -> inventory db, inventory cache

customer client-> CDN, API gateway -> rate service -> rate db

customer client-> CDN, API gateway -> payment service -> payment db

admin client -> CDN, API gateway -> hotel service -> hotel db

admin client -> CDN, API gateway -> room service -> room db

admin client -> CDN, API gateway -> reservation service -> reservation db

Request flows

customer client -> CDN, API gateway -> reservation service -> reservation db, inventory db

customer client-> CDN, API gateway -> hotel service -> inventory db, inventory cache

customer client-> CDN, API gateway -> rate service -> rate db

customer client-> CDN, API gateway -> payment service -> payment db

admin client -> CDN, API gateway -> hotel service -> hotel db

admin client -> CDN, API gateway -> room service -> room db

admin client -> CDN, API gateway -> reservation service -> reservation db

Detailed component design

scalability:

• shard by hotel_id (how to solve hot_shard?) simple implementation
• shard by region/location better performance

concurrency:

• same user double booking/payment, idempotency id: reservation_id
• multiple user booking, i.e. double booking
  • db constraint: remaining >= 0
  • pessimistic locking:
    • SELECT ... FOR UPDATE
    • dead lock
    • timeout
  • optimistic locking:
    • version number
    • not good for high concurrency
• cross service concurrency
  • reservation update, inventory update
  • 2 phase commit: use zookeeper as coordinator
  • payment hold, reservation prep, inventory prep, zookeeper receive votes, zookeeper decision, reservation commit, inventory commit, payment charged.

caching:

• redis
  • key: hotelId_roomTypeId_date
  • val: remaining_rooms
• write to db, then cache, to take advantage of ACID for concurrency issue
• consistency mysql -> redis

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

Failure scenarios/bottlenecks

redundancy on API gateway passive/active

server nodes: N + 1

• listing server: 10 + 1
• booking server: 2 + 1

db: N + 1

Future improvements

allow hourly booking

dynamic pricing

recommendation