Enable users to reserve a parking spot for themselves and park in the spot.
Once user reserves a spot they will get a parking ticket.
Users will have to pay for the parking spot, the payment will be dependent on the amount of time and the type of vehicle of the user.
Users will be able to see the total number of available and occupied parking spots.
If none of the spots are free user will get a validation when trying to reserve a spot.
If multiple users are coming in for a parking spot we will use FCFS algorithm.
Users can pay via the application or by cash at checkout.
Non-Functional:
The system will need to be consistent and it cannot be eventually consistent as if a parking spot has been assigned to a user it cannot be assigned to any other user.
Some amount of latency will be involved in the system as we will need to ensure that the write operation completes for a parking spot.
The system should be fault tolerant.
The system should be available with 99.999% availability.
The system should be able to scale with increased user counts.
Capacity estimation
we can consider each building to have 10 floors and each floor has 100 parking spots.
we can consider daily active users as 1 million across the globe with multiple buildings across the world using our application.
If we consider registration data such as building number, floor number, spot number to be 2 KB for each registration and each user registers 2 times in a day we will have 2 KB * 2 million requests per day for parking registration.
This seems to be a write heavy system as mainly users will be registering for parking spots.
API design
/register - This API will help the user register in the system and add his details such as user metadata and vehicle details.
/login - This API will validate user credentials and help the user login to the system.
/book-spot - This api will help the user book a parking spot, this will take the details of the user such as vehicle type and return the floor and the parking spot which has been booked for the user.
/cancel-booking - This API will help user to cancel his booking for parking in case it is not needed.
/parking-board - This API will get the data for a parking buidling regarding the number of total spots which are remaining for parking.
/payment - This API will help processing of payments from the user accounts, this is an internal API which will then call the payment vendors for processing.
/parking/add-spot This API is for the ADMIN user of the application for adding a parking spot on a particular floor.
/parking/delete-spot - This API will remove a spot on a particular floor to be booked for parking.
/free-spot - This API will free the spot for parking which was previously occupied by a user.
Database design
We can go for a postgres database as we need to store mappings between the user and the parking booked by the user.
We can have a registration table which will store details for every booking, the columns will include, building_id, floor_id, booking_id, user_id.
We will have a user table which will store the user metadata with user_id being the primary key to be used for joins.
We will have a ticket table which will store the details of every ticket generated for the user, these details will include vehicle_license_number, vehicle_type, parking_spot_number.
There will also be tables for building, floors and spots.
Building table can be a partitioned table on the basis of zip_code this will help us to send requests for a particular area to the respective partition.
We will need to lock the read operations for a particular building and floor combination if a write operation is happening to ensure consistency.
High-level design
Request flows
Mobile/Web App (A): This is the client-side application that sends requests to the server.
Load Balancer (B): It acts as a mediator that routes the incoming requests to various backend servers based on the current load they are handling.
Backend Servers (C, D, E): These handle the actual business logic and processes. You have multiple servers to distribute requests efficiently.
Database Load Balancer (F): After backend servers process the requests, they send database operations to another load balancer which manages the requests towards the databases, optimizing load based on their current state.
Database (G): The final destination for data storage where sharding is performed based on zip codes to ensure efficiency and performance.
Detailed component design
Parking allocation - When users will visit the building they will be able to click on the book button upon which the system will show an appropriate parking spot based on the type of the vehicle.
Payment - Once the user is going to checkout the user will be asked to make payment, user can make the payment via the application or they can pay in cash at the checkout.
Trade offs/Tech choices
I have decided to go with consistency as we cannot have one spot booked by 2 users hence we will focus on consistency and latency will be compromised in this case as we will not allow read operations if a write operation is going on.
Failure scenarios/bottlenecks
Increased latency can be an issue as we need to lock reads if writes are happening.
Very high number of writes can be a bottleneck for the relational database.
In case the payment gateway goes, users will need to be forced for payment at checkout, till this time the parking spot will need to be free.
Future improvements
As part of future improvements we can add a caching mechanism to our system to show the immediately available parking spots.
If user is made to select the spot it might happen that 2 users click on the same spot and in this case one of the users will be errored out.
We can think of moving to cassandra to serve for high performant write operations.