Requirements

Functional Requirements:

• The parking lot should manage the entry and exit of cars
• We need to consider the following parameters:
  • Space
  • Accessibility
  • Security
  • Parking Allocation
• The design should accommodate different types of vehicles
• Monitoring, we should keep count of which vehicles have occupied which spaces.
• Add reservation for spaces for certain customers.
• Add payment criteria for normal cars and reservation spots.
• In case of cancellation/no show we should add a penalty that would be suitably applicable for the customer, and open it for other usage
• there should be a time buffer for the reserved customer to show.

Non-Functional Requirements:

• Strong consistency: we should make sure that the same parking spot is not occupied by the same cars
• High availability: have multiple data base and server instances with a load balancer to separate the heavy load.
• Scaling : the system should be able to scale horizontally so that it is able to accommodate more cars
• Performance: the response time for the application should be less than 400ms since it needs to open gates fast.
• Emergency accommodation: in case of an emergency all gates should open and evacuation should be engaged.

Capacity Estimation

Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...

API Design

The API's will be designed as follows

GET v1/lots/getavailablelots - returns a list of available lots which can be taken

POST v1/lots/booklot/{lotid} - this API will book a lot for a user who is entering the parking lot

POST v1/lots/reserverlot/{lotid} - this API will reserve a lot of when a user is booking for future/ the request object will consist of the user id if it is a registered user or the vehicle number for when the user will be arriving it should also contain set the hold time as per default threshold or a user given threshold when up to 30 mins not more than that if the user provides something more than that then it will default back to 30 mins post which the parking lot will be relinquished to the pool.

High-Level Design

From a high level design there are 2 inputs we will have to consider one which is from the user who is entering the parking lot but also from the vehicle parking spaces, since the spaces are segregated between the types of the vehicles it should be updated when it is occupied, hence certain types of vehicles can be stopped at the entrance. The backend services will be different micro services that will be distributed between API gateway that will redirect to Booking service, payment service and availability service. the data base will also have a master and slave model so all the reads can go to the slaves and the write requests can go to the master. But we will also have to add a read after write so that the data bases stay synced.So the user journey will be like the following :

User Entry --> API gateway --> load Balancer --> Booking service --> availability Service --> if available then book and return location number --> Payment service return payment link --> user pays and the slot is booked --> DB for updating record

User exit --> API gateway --> Load balancer --> Booking service --> udpate DB with open slot

User reserve slot --> API gateway --> load balancer --> Booking service --> availability service--> if available then book the slot --> Payment service return payment link --> if payment successful then book slot --> DB update

Database Design

Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns...

Detailed Component Design

ok lets talk about the reservation service or booking service. since this will be handling many cases of double booking and payment confirmation and other aspects as well. this is how we will be handing the different scenarios :

1. Double booking : this is for when a single spot is booked by multiple cars, since the database structure will be such that if the space is booked then one of the columns of fields will be updated, this can only hold 1 value hence this will only happen when a reserved position has been relinquished. at this time the person to whom it was assigned later will hold priority and the new car will have to be assigned another slot hence even the reservation will expire
2. when there is a double commit:Booking commits inside a DB transaction: SELECT ... FOR UPDATE locks the spot row, the transaction verifies no overlapping active hold exists, then inserts the reservation and commits. The first request wins the row lock and commits; the second blocks, re-reads after the lock releases, sees the conflict, and aborts with 409. The client re-checks availability and retries.
3. Idempotent retries: when dealing with multiple requests that will contain the same requests a distributed cache can be implemented which will have UUID keys of the requests or and idempotent key which can be sent as part of the header and when there are multiple requests found then it will reject duplicate requests it will return previous response or reject duplicate requests.