Per request, and incidentally my own habit, notes were taken along the design process.

• Notes are primarily in pure markdown text
• Notes here are meant to capture quick thoughts
  • diagrams or detailed documents will be derived, embedded or referenced as necessary and when ready.

Background Notice

Being an outsider of the hotel business, I actually have no idea how booking works.

When a booking is requested, is a room assigned internally or not? How does overbooking really works.

I am replying on my best guesses in the design:

• A guest may search and book rooms
• when a booking is requested, the hotel checks how many rooms of the requested of a specific type remains and decides where a booking is granted, a room number is associated only at check-in.
• The user may cancel the booking or order shorter than booked nights

Completed Work

• Concept Design
  • Architecure and Selected technology stack verified.
  • a working skeleton set up.

  • all User Cases are all conceptually implemented

    front-end(vuejs page) <--> backend (ASP.Net Core WebAPI) <--> MongoDB

Remaining Work(if time permits)

• implemented details based on unitests, which in turn, needs iterations of domain/business-logic discussions
• UX design

Notes on concurrency

• The requirements hints a message queue e.g. ConcurrentQueue<Action> or a pub/sub frameworks like Redis to be implemented in the the services, which I beg to differ.

The current design uses only one service to talk to the database, and pushed synchronization to MongoDB server with flexible schema, query capability. In case there's performance requirement later, the following is my preferred way.

• the services can scale up with multiple instance deployment like dockers,
• load balance with reverse proxy like Nginx.

Tradeoffs

Due to limited time constrains, some decisions are made in favor of illustrative correctness over production performance

• no login authentication for web services or MongoDB
• no complete UX/UI design, only shows independent services, which is OK for micro services architecture
• test against a clone of development database(i.e. hote_test vs hotel) rather than in-memory mocking frameworks, e.g. ‘moq’
• test cases incomplete

2.3 Assignment Lists

items here are for quick look-up.

All have been reviewed in the design, refer to requirements document.md for details

Details

The following details should be present

• [x] Interactions between users(guests &hotel employees) and the system at different points in the workflow
• [x] All major logical system components, clearly separated
• [x] Any important data used by the system components
• [x] How the system components communicate and coordinate, and any important data that flows or is shared between them

Out of scope

• Managing the of guests checking in
• Multiple hotel locations
• Guest reviews/comments

User Cases

• [x] Use Case #1: Guest searches for rooms by date range, price, and/or type
• [x] Use Case #2: Guest reserves a room by type for a given date range
• [x] Use Case #3: Guest checks into the hotel
• [x] Use Case #4: Guest cancels reservation
• [x] Use Case #5: Guest checks out

Edge Cases

• [ ] EC#1: One room left, two people trying to book the room at the same time- how to handle this scenario gracefully? (note overbooking is OK, but not infinitely!)
• [ ] EC#2: How could no-shows be handled? What is the grace period before a reservation is canceled? Which service owns and triggers the no-show logic?(note: assume the 1-night charge is applied for no-shows!)
• [ ] EC#2: How could no-shows be handled? What is the grace period before a reservation is canceled? Which service owns and triggers the no-show logic?(note assume the 1-night charge is applied for no-shows!)
• [ ] EC#3 How should the system behave when payment is declined at different points in the workflow?
• [ ] EC#4: How would the system deal with guests that want to switch rooms mid-stay? Which services would be impacted by that action?

Modeling Tasks

• [ ] Find the system component boundaries and document them.
• [ ] How many independent services in different contexts/domains could the system be built with?
• [ ] What data does each service own(is the source of truth for)?
• [ ] How is that data leveraged by other services?
• [ ] How do the various UI'S (for both guests and hotel workers )interact with the different services at different points in the workflow?
• [ ] What data do they show? What actions can be executed?
• [ ] What sorts of important business events exist in the system?
• [ ] Which services publish &subscribe to those events? How are the events coordinated between services?

See more detailed response to requirements is here

See also

design document

requirements document