Hotel Reservation System

System DesignScheduling & CalendarE-commerce & Payments

Materials — open to everyone, no sign-in

Topic: Hotel Reservation System

Interviewer: new / xiaoge

Level: L5 (Senior)

Additional Resources:


System Design Interview

Join Us on Wechat

Interview Notes:

7:07 Start of interview

Gathering requirements

Functional requirements

Add background information

Continued functional requirements

Calculation of booking speed

[ could list out the calculation equation used ]

4 million bookings per day = 40 bookings / second

7:20

High level design

Added hotel information service for searching hotel rooms

7:24

Designing database

Payment DB

Room DB

Q: any other DBs?

A: Hotel DB. Room time slot DB

[we may combine some DBs into 1 and use multiple tables in the database]

7:29

[ May want to clarify the ownership of the databases (which service owns which databases) ]

Q: which service owns which databases?

A: DB ownership:

Hotel info service:

Hotel DB

Room DB

Room service

Room time slot db

Q: does Hotel Info Service directly query Room time slot DB?

A: we will add cache to accelerate the queries

[may want to design internal API instead of letting hotel info service to query room time slot DB]

Add reservation DB

7:36

[

Reservation DB: we may want to consider description of reservation without referring to room time slot IDs at the beginning; only add later

Room time slot DB: we may want to consider room type / count, instead of individual rooms

]

Q: walk through a reservation

Booking service -> record reservation in reservation DB

Q: how do we get room time slot ID?

A: Need to add a step before the above, Booking service -> room service to get the rooms available

Booking service will make 2 requests: to room service and payment service

If either requests failed, the booking service needs to rollback the other operation

Q: when booking service calls room service, does it change the room service

3 alternatives to ensure distributed transaction

Two phase commit: requires underlying database support to hold locks and release locks after everything succeeds:

Lock + lock

Write + write

If both succeeds, then commit both side

If either one fails, then rollback both side

Disadvantage: database support to lock. May hold the lock for too long

Try - and - cancel

Each service (payment and room) will change and commit

If either fails, booking service will undo the changes. Requires business logic in the booking service, but it will not lock the table

Issue A&B simultaneously

A, B; A fail, B; A, B fail; A fail, B fail

Saga

Create a list of commands A->B

Send the command to each service sequentially

If any step fails, it will undo the previous steps

The commands are ordered.

I will choose Saga: Reserve room -> withhold fund .

Q: what are the database changes

A:

Change reservation table, set the status to pending [cannot do it due to missing room time slot IDs]

Write to log

Booking service requests room service to reserve room

If failed, the undo

If succeeds, then send command to payment service

Before each step, booking service writes to log, and after each step, writes to log

After room service responds success or failure, writes to log

Q: What database type?

SQL database for most of them

Log: nosql database

7:52

Q: how do we get room time slot IDs

A: user sends room number and dates. Booking service requests room service to get the room IDs.

Q: do we write into the room time slot DBs first?

A: no, we don’t write to the room time slot DB initially

Q: what happens a second user books the same room at nearly the same time?

Audience discussion

Manage the full lifecycle

Combine services. Combine databases

Hotel info service, room service

If we want to emphasize branding, we may want to have separate hotel info service

We may combine databases into one and have multiple tables

This design is similar to design

Room service

Booking service is ordering service

Payment service

May want to add a user service - show IDs

Doesn’t show up

No-show, or cancel

What do we want to do with the user if there is no-show

Wait list

===

Happy case

Prepare1, prepare2

Commit1, commit2

Prepare1 -> succeed, prepare2 -> fail

Rollback1, rollback2

Crash

Prepare1, prepare2

Commit1, crash2, commit2 -> retry forever

Change1

====

Can extend the requirement to include distribution of hotel images/videos

And support property management

1:24:49:10

1:25:47:09