System requirements

Functional:

• Book a parking spot
• Complete a parking spot
• Extend parking spot
• User-friendly interface

Non-Functional:

• Available
• Reliable
• Security
• Scalable

Capacity estimation

Size of parking lot: 500

Average duration of parking per vehicle: 4 hours

Turnover rate of parking spot: 3 times per day

Daily active users = (500 * 3) / 4 = 375 DAU

API design

• /bookParkingSpot - POST
• parameters:
• user_id (uuid)
• vehicle_id (uuid)
• returns:
• Response code: 201
• session_id (uuid)
• Response code: 209
• Message: 'Parking spot unavailable'
• /getParkingSpots - GET
• returns:
• Response code: 200
• Parking spots/costs per 15 minutes (Object)
• /enterGarage - POST
• paramters:
• session_id (uuid)
• returns:
• Response code: 204
• Response code: 400
• /exitGarage - PUT
• paramters:
• session_id (uuid)
• returns:
• Response code: 200
• Response code: 400

• /extendParkingSpot - PUT
• parameters:
• session_id (uuid)
• extension_time (int - minutes)
• returns:
• Response code: 204
• session_id (uuid)
• Response code: 409
• message: 'This parking time frame is taken'
• /cancelParkingSpot - DELETE
• parameters:
• session_id(uuid)
• returns:
• Response: 200
• session_id(uuid)

Database design

User:

• user_id (uuid - PK)
• first_name (text)
• last_name (text)
• is_handicapped (boolean)
• created_at (timestamp)
• updated_at (timestamp)

Vehicle:

• vehicle_id (uuid - PK)
• user_id (uuid - FK)
• vehicle_type (enum - car, motorcycle)
• created_at (timestamp)
• updated_at (timestamp)

ParkingSession:

• session_id (uuid - PK)
• user_id (uuid - FK)
• vehicle_id (uuid - FK)
• parking_spot (int)
• status (enum - scheduled, in_progress, cancelled)
• cost (float)
• session_start (timestamp)
• session_end (timestamp)
• created_at (timestamp)
• updated_at (timestamp)

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

Components:

• L3 Load balancer
• Database (Postgres)
• Cache (TTL cache)
• PSP
• Logger
• Blob store

Request flows

Booking a parking spot:

1. User will enter the book parking spot screen where a request is made to /getParkingSpots. This endpoint will return all the available parking spots that accommodate their vehicle and the price per 15 minutes of parking time
2. User will submit a POST request to /bookParkingSpot
3. The request will then be passed through the L3 load balancer to an available web server
4. The web server will ask the booking service to see whether booking the parking spot is possible and handle payment asynchronously. It will check to see whether the right parking spot is available.
5. On success: The booking service will create a parking session within the database and return the session_id back to the user.
6. On failure: If the booking service is unable to book the spot. It will return a 209 response code to the client.

Enter garage:

1. The parking session will turn the session_id into a QR code.
2. The client can use this code at the entrance where it is scanned.
3. If the parking spot is during the time the user can park. It will open the gate, otherwise a notice will be displayed.

Exit garage:

1. The user can use that same QR code to scan when leaving.
2. This scan will run the business logic to complete their parking session and open the garage door so they can exit.

Extend parking spot:

1. The client can make a request to /extendParkingSpot with the amount of time they want to extend the spot for.
2. If it is not available, they are returned a 409. If it is available they get a 204 meaning it was extended succesfully

Cancel parking spot:

1. The client can make a request to /cancelParkingSpot.
2. If the spot is cancellable (within allowable time frame).It returns a 200

Parking Spot Checker:

1. This is a task that runs every 15 minutes to see if a user is approaching or over their allotted time.
2. If they are over, it will send a message letting the user know that they will face a fine if they do not exit or extend (if possible)
3. If they are approaching the end, it will send a message letting them know that they parking spot is about to expire.

Detailed component design

Database:

Consistency would be key especially when payment is involved. For this reason, we want to have a good replication strategy in place for the databases. We can have 1 write database that would synchronously write to the read database as well as a replica in case one of them fails. In this case, the replica could take over. We can utilize primary-secondary replication.

Cache:

We could use an LRU cache for this application so that we are not needing to fetch data from the database when it comes to upcoming parking sessions. We can also evict when a parking session is completed.

Parking Spot Checker:

This service would be a scheduled task runner where it would run every 15 minutes and check for whether a parking spot is coming to an end or if the user is over their allotted time for parking. Each of these situations would send a push notification to the user. When a user is over their allotted time, we can also enforce fines or overtime fees.

Trade offs/Tech choices

The replication strategy we use for our database has a performance trade-off that i believe is necessary for us to have strict consistency when it comes to user parking. This is because there is money involved and using an asynchronous replication strategy can lead to lost data, where we have already taken money from the user.

Failure scenarios/bottlenecks

I see Parking spot checker being an issue where it can put a lot of stress on the on the database.

Future improvements

In such a case, it may be a good idea to put a cache in the middle where we populate the cache based on active parking sessions.