Great explanantion. To serve more read, we can create secondary noes of db (CQRS).
@ashishrawat770
Жыл бұрын
Wow!, so many concepts in a single video. Thanks a lot brother!!
@irtizahafiz
9 ай бұрын
Glad you found it helpful! Cheers.
@rajeshkishore7119
6 ай бұрын
Excellent, room booking could have been covered with more detailed with rdbms isolation support
@jacob5253
2 жыл бұрын
It might be helpful to include some talk/discussion for ASYNC MQ / retries wherever possible in this system, this kind of system might not be scaled to that condition, but it's worth discussing with interviewer.
@irtizahafiz
2 жыл бұрын
Yeah! Those are always good things to discuss with interviewer. Also, if the interviewer really cares about it, they will also prompt the candidate to talk about async processes.
@lunaxiao9997
3 ай бұрын
For peak hours, there should be a lot writes too
@shrimabaskar
2 жыл бұрын
I think it would benefit to talk a bit about the service architecture, is there going to be multiple services (each with its own database) or a monolith. In case of a micro service architecture, we have to make sure we do distributed transactions.
@irtizahafiz
2 жыл бұрын
Thank you for the suggestion! I tried to keep it simple to give a high level picture rather than dive into the details which might confuse some people.
@ziggyzhang4156
Жыл бұрын
I feel like if the system is anywhere near expected large scale and we are already talking about sharding databases, distributed transaction in this case is inevitable. Unless we have both entire reservation table and inventory table living together on a single database instance node with no sharding, we need something like 2 phase commit to achieve distributed transactions.
@ziggyzhang4156
Жыл бұрын
And regarding you using row versioning as optimistic locking approach, I'm not sure if that will work if that database change also needs to be a part of a distributed transaction using two phase commit? Basically by using 2PC in Prepare phase, an explicit lock has to be acquired on both inventory and reservation databases, as otherwise between Prepare and Commit, another thread could be changing the value if Prepare phase only ensures what it's about to write at the time was the up-to-date value.
@lihewang6532
Жыл бұрын
I am a little confused by is_available column in Room table. Should it also have a Date column? since the room is usually available on certain date and not available on other date.
@prajyotlawande193
4 ай бұрын
Excellent explanation. 👌🏼
@michealzhang8776
3 ай бұрын
Nice design Bro, if you could share the system diagram that would be great!
@irtizahafiz
3 ай бұрын
Thank you for watching! Unfortunately, I lost all the system diagrams :(
@jannismucke588
2 жыл бұрын
Thank you for your clear explanation. Keep it up
@irtizahafiz
2 жыл бұрын
Glad it helped : )
@rudeadyet1992
Жыл бұрын
thanks for this. very helpful. looking forward for the actual application video tutorial, that would be awesome.
@irtizahafiz
9 ай бұрын
That's an idea I am playing around with. It's just a ton of effort and I am not sure how many people will actually watch a 2-3 hours long video.
@thijs7448
9 ай бұрын
@@irtizahafiz Would be very interesting
@rudeadyet1992
9 ай бұрын
@@irtizahafiz I would enjoy and appreciate every bit of it and sure everyone would as well! :)
@senwang8670
7 ай бұрын
on "How to avoid multiple users reserving the same room", isn't the reservation based on room type not specific room_id? you just need to increase the total_reserved value. The problem should be how to avoid over booking.
@sweetpotatoeater3169
2 жыл бұрын
Amazing content
@hazemabdelalim5432
Жыл бұрын
you didn’t discuss the consistency in replica ? ( read after write ) ? also how would u handle the intersections between dates ?
@irtizahafiz
9 ай бұрын
If you want strong consistency, you can either use a relational DB or tune your non-relational DB to have consistency (at the expense of availability).
@timewarptrio11
Жыл бұрын
very helpful!
@tello9504
2 жыл бұрын
Daaaamn, nice! Can you talk about how to calculate costs ?
@irtizahafiz
2 жыл бұрын
Hi! Yes! I do have a video on that coming up, on how to do back of the envelope estimations to get a sense of scale.
@schan263
7 ай бұрын
Your design doesn't support multiple rooms reservation?
@irtizahafiz
7 ай бұрын
It should be relatively easy to expand to that use case.
@jonamep
Жыл бұрын
How would be treated reservations that are not continuous ? For instance a user that booked day 1 and day 4 of the month only.
@irtizahafiz
9 ай бұрын
That's a great question! I don't think I can answer that without going into specifics. I will make a note for a future video.
@Anteater23
10 ай бұрын
How does the database keep track of how many rooms a particular hotel has on a specific date??
@irtizahafiz
9 ай бұрын
You can just store by in a relational table.
@Luduin
Жыл бұрын
I found this by chance. You don't do videos showing the coding or have the repository with such codes do you? As usual, i try to follow tutorials both to learn and to check if i can find different solutions. Im a beginner.
@irtizahafiz
Жыл бұрын
Hi, sorry! These are more from a conceptual point of vide. Don't think it's practical to code all these up. If you do want to look at some code though, for all my app builds in this channel, I link the code in the video description.
@Gryseaa
Жыл бұрын
Great content! Have one question please. For user try to search the hotel by location(latitude, longtitude), I am thinking try to use Quartree to split the world to small grids, for each grid we can hash to a key, and value would be the hotel lists. These data we can use for our indexer service, we do not need to search the location in huge world map data anymore. But how we can store this Quartree data and how we can sharde the data please? if sharding the data by the grid key, what if some grids(locations) are too popular, then data servers are overloading.
@stephanbranczyk8306
9 ай бұрын
Personally, I'd use geohashing instead of quadtrees. They're similar concepts, but with geohashing, you'd just store a String for the geohash you want and you'd keep indexes of your hotel ids that way. As to server overloading, same idea, you could cache some of those indexes. Also, it's not like your list of hotels will change very much. (disclaimer: I'm not an expert. If I made a mistake in my reasoning, I'd welcome any correction).
@erfannariman
2 жыл бұрын
Nice video as always, thank you for that! Just to be sure, in this data model, aren't you missing some kind of "fact" table. So if you want to look up when someone made a reservation, that is not possible with this data model, right?
@irtizahafiz
2 жыл бұрын
Hi! Glad you enjoyed it : ) The idea I was going with here is that your "reservation" table will be the source of truth for all reservations. You can have a foreign key of "guest_id" for every reservation so that you can easily look up active/cancelled reservations by the guest_id.
@user-eq4oy6bk5p
2 жыл бұрын
Can idempotency key be generated on client side? I've seen a client application passes UUID as idempotency token and backend will check if the client has passed the same key
@irtizahafiz
2 жыл бұрын
Hi! Yes you can generate it on the client side too. But I would recommend just generating a reservation_id on the backend, so that you can use the unique constraint on your database rather than relying on client.
@joesmith8462
Жыл бұрын
Great content. Where would you recommend we go for the actual API? If you have a specific subset of 1000 hotels, would you aim to make deals directly with the channel managers or obtain rates from somewhere like an aggregator or bed bank which would sacrificing a big portion of the commission? Any feedback deeply appreciated!!!!!!!!
Пікірлер: 43