Loading...
List functional requirements for the system (Ask the chat bot for hints if stuck.)...
1. The Parking Lot system should be able to record a car's number on entrance and notify the driver about its parking lot
2. The system should be able to recognize the car's dimensions and allocate a space based on that
3. During the exit, the system should identify the car's number and calculate the time it has spent on the parking lot. Based on that, it should calculate the parking cost.
4. The parking lot system should also gather the data from the distributed cameras in real-time and notify the administrator whenever illegal activities are done.
List non-functional requirements for the system...
1. Availability. The system should be highly reliable and error-prone because the parking service usually is working 24 hours a day. Once launched, the service should operate at 99.9999% of the time.
2. Security. The system should be highly secure. The user data should be encrypted and nobody can trace an allocated parking lot of each user.
3. Performance. The system should be highly responsive. The search for a parking lot should be quick taking no more than 1 or 2 seconds. The operation of reserving a parking lot should take no more than 1 second.
4. Scalability: The system should be able to handle increasing number of vehicles and users.
Estimate the scale of the system you are going to design...
Let's assume that the parking lot system operates in 200 cities. Each city on average has 20 parking buildings that uses our system. Each parking building is able to allocate around 200 vehicles, in which 180 are casual cars and 20 for trucks. Now, let's assume that the average time of keeping a car on a parking lot is 2 hours. Let's also assume that the drivers quickly fill all the allocated space. So, we may assume that there are around:
200 cities * 20 parking buildings * 200 vehicles = 800000 users that start interacting with our system daily
The number of operations for entering a parking or exiting would be 800000 requests per day.
The number of operations to search a parking lot and reserve it would make additional 1600000 requests.
Considering that 20% of the users would cancel their reservations and reserve another spot adds additional 320000 requests.
Overall, the system should be able to handle 800000 + 800000 + 1600000 + 320000 = 3520000 requests per day.
Define what APIs are expected from the system...
1. APIs for entering and exiting the parking lot
/enter-parking/{buildingId}/{userId}
/exit-parking/{buildingId}/{userId}
2. APIs for reserving a spot in the parking lot
/reserve-parking/{buildingId}/{spotId}/{vehicleId}
/cancel-reservation/{buildingId}/{spotId}/{vehicleId}
Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...
DB Schemas:
User {
userId integer PK,
full_name varchar,
phone varchar,
password varchar
}
Vehicle {
vehicleId integer PK,
type "Truck" | "Car"
userId integer FK references User(userId)
}
Parking {
buildingId integer PK,
car_spots_count integer,
truck_spots_count integer
car_reserved_spots integer,
truck_reserved_spots integer
}
Spot {
spotId integer PK,
spotType "Truck" | "Car"
buildingId FK references Parking(buildingId)
}
You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...
Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...
1. The client or a driver sends a request to a server. But before reaching a server, it goes to load balancer to deliver traffic uniformly among the servers.
2. Once the request reaches the server, rate limiting service checks whether particular user has not been sending already too many requests. In case if not, the server gets the user's request.
3. Based on the user request which can be entering, exiting, reserving a parking spot or cancelling, the server would handle the particular logic by sending the corresponding request to a database. The request can be also called as a transaction.
4. If the request is read-only like checking the available reservations, the server should also check the Redis cache first. Otherwise, it goes for the database
5. Database transaction is stored in the transaction queue and awaits its execution
Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...
Explain any trade offs you have made and why you made certain tech choices...
Try to discuss as many failure scenarios/bottlenecks as possible.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?