System requirements

Functional:

List functional requirements for the system

1. Record entry for the vehicles
2. Record exit for the vehicles
3. Allot parking space to the vehicle

Non-Functional:

List non-functional requirements for the system...

1. Availability
2. Scalability
3. Accessibility

Capacity estimation

Estimate the scale of the system you are going to design...

Lets say every minute 10 vehicle comes

Assuming Vehicle_Number is 8-10 character long. Same for alloted parking spaceID 8 character long string

1. Vehicle_Number (8byte)
2. Owner_Name (20 byte)
3. EntryTime (8 byte)
4. ExitTime (8 byte)
5. AllotedParkingSpaceId (8 byte)

Each entry is 52 bytes

Estimated per day cost: 10*24*60*52 = 748800 byte = 731.25 GB

API design

Define what APIs are expected from the system...

API: EnterVehicle()

Assign an available space to newly entered vehicle

ExitVehicle()

Mark the assigned space for the leaving vehicle/car as available.

Database design

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...

Needed entity in the DB

1. Vehicle_Number
2. Owner_Name
3. EntryTime
4. ExitTime
5. AllotedParkingSpaceId

Mapping for Vehicle_Number -> AllotedParkingSpaceId

High-level design

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...

sequenceDiagram

actor A as Vehicle

participant E as Entrance Gate

participant S as Parking System

participant D as Database

participant X as Exit Gate

A ->> E: Arrives at entrance

E ->> S: Scan/Enter vehicle details

S ->> D: Check available parking spaces

D -->> S: Return available space

S ->> D: Store vehicle details and assign space

D -->> S: Confirmation

A ->> X: Arrives at exit

X ->> S: Vehicle exiting, scan vehicle number

S ->> D: Find vehicle record

D -->> S: Return vehicle data

S ->> D: Update exit time, release space

D -->> S: Confirmation

Request flows

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...

EnterVehicle() API:

Client sends the request with the vehicle and its owner data. It create a mapping for Vehicle_Number - > Available_Parking and store it in the database.

ExitVehicle() API:

Client sends the request with vehicle details and it removes the mapping for this vehicle and update the database.

Detailed component design

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...

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

Ways find and assign the available parking:

1. Hash or Array to assign and store the information on of assigned space.

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

1. No available space to assign to the new coming vehicle
2. Failure in mapping service
3. Taking a lot of time to find the available spot.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?

1. Adding payment system
2. Support for reserved spot
3. Support and handle case for peak demand hours
4. Support for security feature.