Loading...
Search : Provides option to search available rooms based on dates and capacity.
Booking: Can be blocked the room based on the request.
Manage Booking : We can update/cancel of the booking made by the owner of the bookings.
1) Highly Available.
2) Consistent.
3) Scalable and performance
4) Security
DAU = 10K
50% DAU do search and 20% users do the booking
Booking data can be 10 kb in size
Storage = 20%*10k*10KB = 20MB daily * 5 years = 36.5 GB
1) GET /api/v1/search/{date}
api/v1/search/{date}/{count}
The response of the API will return the list of rooms available with the max number of member can be allocated .
2) POST /api/v1/book
parameter : { date ,count,user_id}
response will be 201 created
3) PUT /api/v1/modify
parameter {booking_id}
reposne will be 200 updated
Room :
room_id : UUID
room _name:String
location:string
capacity:Int
primary key : room_id
Booking:
booking_id:UUId
room_id: uuid
user_id:uuid
date
status:created/cancelled
primary key = booking_id
foreign key = room_id,user_id
index the table based on date.
1) User search for availability via search service and get the rooms available . User -> Api Gateway -> Search Service ->Redis
Redis is used to get the faster result and Redis will get populated via CDC pattern ,so that updated data are available.
2) User do booking via booking service and the booking record will be stored in DB
1) For real time availability we use CDC pattern to update the cache on real time change and follow read through cache strategy.
2) For booking we use pessimistic locking to lock the record users when doing the booking .
1) We are using API gateway for user authentication ,rate limiting and as service discovery.
2) we are using horizontal scaling for both of the services .
3) we are also using redis stecil for managing the scalability and availability of cache.
1) We are currently using pessimistic locking which will lock the table and performance of the system will degrade ,we can use optimistic locking in-place .
2)Currently we are using Redis as cache to serve the availability request
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?