System requirements

Functional:

• Modern parking lot system for entry exit and parking allocation
• Different types of vehicles
• Consider space optimization, accessibility, security and user experience

Non-Functional:

• Accessible
• Available
• Scalable

Capacity estimation

• Assuming 10000 people park a day
• Assuming 1000 new users a day
• Assuming 500 parking spots

Calculation for User Table:

Assuming first names and last names are 10 characters each

Assuming Payment information is 12 characters each

Assuming UserID is base64 encoded -> 6 bytes

Every row would be 38 bytes

38 * 1000 = 38 000 bytes -> 38 KB per day

Calculation for Parkade Table:

Assuming UserID is base64 encoded -> 6 bytes

Parking spot -> 4 bytes

License Plate -> 6 bytes

Type -> 1 byte

Exipry Time -> 5 bytes

22 * 10 000 -> 220 000 bytes -> 220 kb

Calculations for Parking Spots Table:

ParkingID -> 4 bytes

Type -> 1 bytes

Available -> 1 byte

API design

External:

POST:

• /park
• parameters:
• Spot Number
• UserID
• Time

GET:

• /getUser
• parameters:
• UserID

GET:

• /parkingInfo
• parameters:
• ParkingID

Internal:

GET:

• /getParkingSpot
• ParkingID

Database design

User Table:

• UserID (VARCHAR)
• First Name (VARCHAR)
• Last Name (VARCHAR)
• Payment information (VARCHAR)

Parkade Table:

• UserID (FK VARCHAR)
• Parking ID (INT)
• License Plate (VARCHAR)
• Type (CHAR)
• Expiry Time (DATETIME)

Parking Spots Reference Table:

• ParkingID (INT)
• Type (CHAR)
• Available (CHAR)

High-level design

• Might want a CRON job to clear out Parkade Table by removing all rows with current time > expiry time to clear up DB space

• User selects available spot to see price and can decide to pay for it

• User can check whenever they want to see when parking expires

Request flows

• User selects spot
• When selected, GET /parkingInfo will get the parking information and display to user
• Note application code will generate price per hour depending on type of parking spot fetched from Parking Spots Reference Table

• User pays for spot by sending POST request to /park
• Application code will get the expiry datetime
• Application code will pay third party app
• Application code sends to internal GET /getParkingSpot to check if spot is available, proceed if available
• If payment is succesful, ADD or UPDATE UserTable
• Update Parking Spots Reference Table to reflect that the spot is taken

• If user wants to check in time remaining, GET /parkingInfo will be able to grab that date
• Grab from Parkade Table

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

Failure scenarios/bottlenecks

Bottle neck could be if there are too many people trying to see when their parking expires

-> Use DB replicas -> This case synchronous because we want to be sure to only allow user to pay for spots that are available, its okay if they have to wait a second or two to grab this information, the tradeoff is worth it

Bottle neck could be if theres too many people trying to pay at once

-> Shard the database to alleviate too many writes to a single DB

-> But in this case because theres only 1000, this shouldnt be an issue

Possibly if payment fails but because we are using a third party app, they should probably already be handling retries but we can still retry request to third party app if the payment fails

Future improvements

Depending on what users are looking for, we can build new features