System requirements

Functional:

• assign parking spot upon vehicle entry
• release spot upon vehicle departure
• reject entry if no spot is available for vehicle type

Non-Functional:

• authentication required
• strong consistency
• high availability
• scalability

Capacity estimation

• every 20 seconds we have a user enter or exit
• 26mb for parking spot data
• 949mb for user data over 10 years

API design

GET "/parking_spots/:vehicle_type"

{

parking_spots: [......]

}

POST "/parking_spot/reserve"

{

parking_spot_id: ...,

timestamp: ...

}

POST "/parking_spot/release"

{

parking_spot_id: ...,

timestamp: ...

}

Database design

Parking Spot

• id - int
• vehicle_type - string
• status - string(taken, available)
• last_updated - datetime

User

• id - int
• first_name - string
• last_name - string
• password - string
• email - string
• current_parking_spot - int

High-level design

Api gateway. Reservation Service. Load balancer in front of reservation service. Distributed lock(reddison). Postgres DB.

Request flows

Once a user authenticates and wants to reserve a spot, user will request parking spot based on vehicle type. User will then select the spot which will reserve the spot, authentication will work based on session cookies. We will use a distributed lock(reddison) to ensure the spot is available. If the spot is reserved out reservation service will send an error back to the user and if the spot is available we will update the user record current parking spot attribute with the parking spot id and update the status of the parking spot record to taken and then release our distributed lock. Once the user wants to release the spot they will go through the application, exit the parking lot and click a release button which will update both the user record parking spot id to nil and update the parking spot record to available.

Detailed component design

Once a user authenticates and wants to reserve a spot, user will request parking spot based on vehicle type. User will then select the spot which will reserve the spot, authentication will work based on session cookies. We will use a distributed lock(reddison) to ensure the spot is available. If the spot is reserved out reservation service will send an error back to the user and if the spot is available we will update the user record current parking spot attribute with the parking spot id and update the status of the parking spot record to taken and then release our distributed lock. Once the user wants to release the spot they will go through the application, exit the parking lot and click a release button which will update both the user record parking spot id to nil and update the parking spot record to available.

Trade offs/Tech choices

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

Failure scenarios/bottlenecks

We will have a master slave system where we duplicate our current database on a secondary server in case one server fails, we will spin up a replica of the secondary server and make the secondary server take over the master system and the replica be the new secondary server. We will also periodically dump our postgres DB in case it fails. If the postgress db does fail we will use the dump of our database and spin up a new server with the dump image.

Future improvements

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