Yeah, i also think the same but after deep consideration when creating or manipulate hotels data, we need to update it in two place. Which is Elastic Search And database. We need to store in database first and after that we need to move the data to elastic a do reindexing.
@@dev_yethiha that's fine, that's something pretty basic that most web apps do. You don't need to decouple these requests with an intermediate queue for that though. You can just trigger the Elasticsearch update in response to DB updates, without hurting the UX of a request that the user doesn't know if it succeeded or not anymore. Imagine a user trying to make a bunch of changes in their admin dashboard and having to refresh the browser after each step because they're not sure if the last update succeeded or not.
The hotel creation side seems a bit overengineered, or at least not well-justified... Why do we need an "Admin Queue" - is hotel/room creation really that frequent and resource intensive? And who is being notified about hotel/room creation?? I'm sure one could come up with reasons, but without explicitly stating said reasons, it seems unnecessary.
Is room_inventory table along enough for the booking availability search within a date range? What if I would like to book a room for 3 consecutive days and there is an availability for each particular day, but there is no consecutive availability of a particular room. There could be 3 different rooms available at every particular day within a date range.
Yes, you are correct. I think to prevent this error and make it simplier we would have to calculate each time a client asks about specific range (and maybe store it in some cache) from reservation table. Something like this I think WITH ReservedRooms AS ( SELECT roomId FROM reservations WHERE roomTypeId = @roomTypeId AND ( (CheckInDate @startDate) ) ) SELECT roomId FROM rooms WHERE roomTypeId = @roomTypeId AND roomId NOT IN (SELECT roomId FROM ReservedRooms);
DB tables should be the result of clear separation of responsibilities and domains. Starting with db tables to system design can mislead younger developers
![[#2024MAMA] ROSÉ (로제), Bruno Mars - APT. | Mnet 241122 방송](http://i.ytimg.com/vi/dgGqD28J6aQ/mqdefault.jpg)
This confirmed my head was in the right place. Didn't think of the idempotency stuff tho. Thanks well explained.
Thank you!!
What sort of intense processing is being done to create hotels? The message queue on that path seems a bit overkill.
agree, over design.
Yeah, i also think the same but after deep consideration when creating or manipulate hotels data, we need to update it in two place. Which is Elastic Search And database. We need to store in database first and after that we need to move the data to elastic a do reindexing.
@@dev_yethiha that's fine, that's something pretty basic that most web apps do. You don't need to decouple these requests with an intermediate queue for that though. You can just trigger the Elasticsearch update in response to DB updates, without hurting the UX of a request that the user doesn't know if it succeeded or not anymore. Imagine a user trying to make a bunch of changes in their admin dashboard and having to refresh the browser after each step because they're not sure if the last update succeeded or not.
Thanks for sharing such valuable content soo helpful brother💪
Appreciate the kind words!
What tool are you using to create these diagrams?
eraserio
Keynote!
Well explained.
Thanks!
Good explanation
Thank you!
The hotel creation side seems a bit overengineered, or at least not well-justified... Why do we need an "Admin Queue" - is hotel/room creation really that frequent and resource intensive? And who is being notified about hotel/room creation?? I'm sure one could come up with reasons, but without explicitly stating said reasons, it seems unnecessary.
100%
Is room_inventory table along enough for the booking availability search within a date range? What if I would like to book a room for 3 consecutive days and there is an availability for each particular day, but there is no consecutive availability of a particular room. There could be 3 different rooms available at every particular day within a date range.
Yes, you are correct. I think to prevent this error and make it simplier we would have to calculate each time a client asks about specific range (and maybe store it in some cache) from reservation table.
Something like this I think
WITH ReservedRooms AS (
SELECT
roomId
FROM
reservations
WHERE
roomTypeId = @roomTypeId
AND (
(CheckInDate @startDate)
)
)
SELECT
roomId
FROM
rooms
WHERE
roomTypeId = @roomTypeId
AND roomId NOT IN (SELECT roomId FROM ReservedRooms);
next one in telegram all feature 😄😄
DB tables should be the result of clear separation of responsibilities and domains.
Starting with db tables to system design can mislead younger developers