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.
• API for monitoring input for check in and check out of vehicles to make sure all dues are paid, else ask to clear dues before leaving.

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

For the capacity estimation we should assume for 1 lotthe following:

• The amount of traffic that we will be getting would be around 50 cars per hour assuming that we operate 14 - 16 hours a day lets assume that we will be getting between 700 - 800 cars moving in an out. so the read to write ratio will be pretty even here when searching and updating a booking for a spot. but if we add the changes required for payments then the ratio shifts in the number of writes that we will be doing. so in conclusion this will be a comparatively write intensive database hence cassandra is a good option for this.
• another aspect is going to be the QPS which will be 50 cars lets assume number of cars going in will equal to number of cars going out hence the payment gate way will be split between cars going in and reservations that have been done so about 75 read writes in an hour give or take 10-20% variance.

Keeping the above in mind if we scale to 10 countries x 100 lots across countries these numbers get larger very fast hence it brings into concern more and 800000 cars a day across continents and the application officially operating 24 hours. we are looking at a much higher load. following are some quick calculations :

• so in an hour if we take 75 read writes and multiply that by 100 we will get the following 75000 which results in 1250 queries per second hence the if we assume approximately 200 of them are reservations lets assume about 2000 queries per second with a write to read ratio of 2:1.
• now for storage size if we for teach transaction it takes about 128 bytes when calculated that with 2000 queries out of which 1200 are write queries results in about 153600 bytes/s i.e. 540 MB /hour

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

The database that I will use is a noSql data base since the number of relations are lesser and it is a highly read write intensive data base also replication in case of the NoSQL data base is better when creating clones hence I will use Cassandra for example. for larger loads we can perform sharding to break down the database reads into smaller chunks at the routing layer using a stateless proxy instances between the service and the database

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.