- Introduction
- Prerequisites
- Technical Specifications
- Local Run
- Testing h2
- Mind map
- Sequence Diagram
- Data structures
- Project Details
- CICD pipeline
- API Documentation
- Future enhancements
- Application to reserve room based on the availability
- Docker installed
- git to pull the code
- Springboot framework version 3.2.0
- Java 17
- Redis for caching
- H2 for database
- Docker for containerization
- Spring scheduler for scheduling daily operations
- Checkout the code from github master branch
- docker pull shobhakamath/conference-booking-service:latest
- Run docker compose up --build
- Run docker compose down to down the application
- http://localhost:8080/h2-console/login.do
- JDBC url: jdbc:h2:mem:rooms
- Username: sa
- Password: password
sequenceDiagram
participant User
participant BookingService
participant ConcurrentQueue as LinkedTransferQueue
participant ReservationRequestConsumer
participant ReservationService
participant RoomService
participant SchedulerService
participant RoomReservationBinarySearchTree
User->>+BookingService: POST /v1/bookings
BookingService->>ConcurrentQueue: Push the CreateBookingDTO to the queue
BookingService->>-User: Acknowledgement with id 200 OK status
ConcurrentQueue-->>+ReservationRequestConsumer: The consumer is a runnable task which reads the CreateBookingDTO from the LinkedTransferqueue
ReservationRequestConsumer-->>+ReservationService: Calls the reserve function
ReservationService-->>SchedulerService: Check if there are overlapping maintenance schedule
ReservationService-->>RoomService: Check the tentative rooms based on the no of persons and the seating capactity of the room
ReservationService-->>RoomReservationBinarySearchTree: check if reservation can be done for the given time and the duration
ReservationService-->>ReservationService: Persist reservation in database
ReservationService-->>-ReservationRequestConsumer: success
ReservationRequestConsumer-->>-ConcurrentQueue: The consumer thread runs indefinitely consuming the requests
sequenceDiagram
participant User
participant BookingService
participant ConcurrentQueue as LinkedTransferQueue
participant CancellationRequestConsumer
participant ReservationService
participant RoomReservationBinarySearchTree
User->>+BookingService: DELETE /v1/bookings
BookingService->>ConcurrentQueue: Push the CreateBookingDTO to the queue
BookingService->>-User: Acknowledgement with id 200 OK status
ConcurrentQueue-->>+CancellationRequestConsumer: The consumer is a runnable task which reads the CancelBookingDTO from the LinkedTransferqueue
CancellationRequestConsumer-->>+ReservationService: Calls the cancel function
ReservationService-->>ReservationService: Check if the booking is available
ReservationService-->>ReservationService: Delete if its available
ReservationService-->>RoomReservationBinarySearchTree: Remove the node from the BST
ReservationService-->>-CancellationRequestConsumer: success
CancellationRequestConsumer-->>-ConcurrentQueue: The consumer thread runs indefinitely consuming the requests
The following data structures are used to improve the concurrency, consistency and better optimization.
The LinkedTransferQueue belongs to java.util.concurrent package.The elements in the LinkedTransferQueue are ordered in FIFO order and are thread safe. In scenarios where there are multiple producers and consumers contending for access to a shared queue, the transfer mechanism of LinkedTransferQueue can reduce contention. The direct handoff between threads minimizes the time elements spend in the queue and reduces contention on the queue itself. The ordering of elements is based on the order in which threads arrive, providing reasonable performance in various scenarios. The time complexity is O(1) for insertion and the transfer operation.
ConcurrentHashMap is a class in Java that provides a high-performance and thread-safe implementation of the Map interface. It is particularly useful in scenarios where multiple threads need to access and modify a shared map concurrently.Hashmap provide get() and put() operations with time complexity of O(1).
The reason for using BST for the reservation system is that: The use of BST optimises the search ,insertion and deletion operations in the complexity of the order O(logn).
The node in the BST are created in the order of requests. Each node is composed of the data structure { element:LocalTime, duration:long } Each node can have a left and a right node. Below shown a BST with nodes elements and their child nodes
Inorder traversal of the BST gives : [(6:01,30),(7:29,30),(8:00,30),(9:32,30),(10:32,30),(11:32,30)]
graph TB;
A((8:00,30))-->B((6:01,30))
A-->C((10:32,30))
B-->D(null)
B-->E((7:29,30))
C-->F((9:32,30))
C-->G((11:32,30))
- The reservation uses Binary Search tree to book the room.
- The room details and the maintenance schedule is saved in the database using migration scripts
- On system startup, the maintenance booking is reserved in the reservation system.
- The BST tree is created from the reservation bookings.
- The tasks ReservationRequestConsumer and CancellationRequestConsumer tasks are started which runs indefinitely.
- The scheduler runs every midnight to clear the caches and to create the maintenance schedule for the rooms.
- On the create booking API call, the user request is pushed to the LinkedTransferQueue
- The ReservationRequestConsumer reads the request from the LinkedTransferQueue and calls the ReservationService.
- The ReservationService will reserve the room based on the rules:
- Should not be within the maintenance schedule
- Should not overlap any existing bookings
- The reservation is created in the database and the BST cache
- On the delete reservation call,the user request is pushed to the LinkedTransferQueue
- The CancellationRequestConsumer listens the request and calls the ReservationService for room cancellation.
- The ReservationService will check the booking and if it exists it will delete from both the DB and the cache.
The CICD pipeline is setup.For each commit,the project will be packaged and image will be pushed to dockerhub.
API documentation can be found by navigating to http://localhost:8080/swagger-ui/index.html#/
- Integrating a user service and spring security to implement the RBAC of the APIs.
- Cache clear for the different caches in the application
- Few extra validation in the APIs
- The failure requests could be logged to the database. It increases the scope of the problem in question.
- CICD pipeline and deploying to server.