Loading...
The parking garage should support vehicles of multiple sizes, a sedan, a truck, motorcycles
A sedan may fit in a truck or sedan spot
A truck may only fit in a truck spot
A motorcycle may fit in all spots
A customer may pay on the way out of the parking garage or book in advance
Customer should be able to book a parking spot in advance
Customer should be able to see their reservation if available
The service should be highly available and consistent
Assuming this parking garage operates at a popular city, we can assume that the parking garage has a capacity of 200 vehicles and about 1000 customers go in and out daily. Because issues can occur, we should keep all these transactions for around 1 year. 1000 * 365, we need to be able to save about 365 million records
We need 5 API's, 1 for reserving, 1 for checkout, 1 for viewing parking garage, 1 for registering user, 1 for viewing reservations
For database, we need 3 databases 1 for users, 1 for reservations, 1 for the parking garage itself
For the user, we need to store all the user information such as customer id, contact information, etc
For the reservation database, we need to store customer to store users mapping to their reservations
The parking garage database will be used for mapping the garage spots and their size along with their availability and if not, who reserved or is using the spot
At a high level, we need a load balancer to ensure we keep from overloading a single server, an api gateway that will handle authentication, a server that will handle logic for booking and retrieving information, databases to store data, a payment checkout service that will take care of processing payments
The first usecase is for registering.
The user will fill out the form and the register api wil be called that the server will save into the user database
The first use case of request flow is booking.
The customer will first load the site and the view parking lot api will be called to view what spots are available from the parking garage database then the user can proceed to the next usecase where the user checks out
The second use case of the request flow is checking out. The user will submit their payment information and the server will use a third party provider to use process the payment
The third usecase is for viewing reservations. The user goes to their profile and view reservations api and the load balancer will call the server and will call the database that returns the reservations for a given user.
For the database, we want to make sure that it is highly available and consistent which can be achieved with replication of databases. With replication, it can handle many database reads
We should use a relational database such as RDS due to the information overlapping between tables such as users and reservations and the parking garages
Failure scenario will be when the load balancer fails as a single point of failure.
In order to avoid single point of failure we can also scale the load balancer horizontally or we can implement a microservice architecture and each will take care of handling a single process. 1 for payment, 1 for entry and exit, another for viewing reservations, etc