System requirements

Functional:

• Customer accounts
• User management
• Vehicle entry
• Vehicle exit
• Parking allocation

Non-Functional:

• Scalability: we assume that this system can be used for multiple car parks.
• Availability: parking spots should be used frequently and with variable timeframes, so their data should be highly available at all times.

Capacity estimation

Assuming 100 spots per car park and each customer can have n amount of car parks.

Each card record could be around 50 bytes, we are talking about 5KB of car data per parking lot at maximum.

Assuming similar numbers for parking spot data, with the difference that this is a fixed capacity, as each car park will have a max capacity that wont change.

We can start with customers that can have up to 10 car parks per account, that makes a total of 100kb per customer account when operating at max capacity.

For user management lets assume half size (than parking spots or cars) per record. 25 bytes per user, and estimating an edge case (max) of 10 employees needed to manage a parking lot of 100 spots, makes it 250 bytes per parking lot.

Accounts will hold references to most data, plus account data, so we can aim for double the size of a car or a parking spot record. 100 bytes per record.

To summarise:

• Account - 100 bytes
• Users - 250 bytes per account
• Parking lots - 10kb (which includes car and parking spot data)

We can allow 11 kb per customer account. We can start with 100 customers (1.1 mb) and with a db that has autoscaling capabilities we wont need to worry about running out space for very long time.

Reads and writes are quite frequent for car and parking spot data, but we can handle that with a caching mechanism like Redis to allow for high availability and performance.

API design

v1/users/create - POST

v1/users/remove - DELETE

v1/account/create - POST

v1/account/details - GET

v1/account/edit - PUT

v1/account/lots - GET

v1/account/lots/spots - PUT

v1/account/lots/spots/availability - GET

v1/cars/ - GET

v1/cars/entry - POST

v1/cars/exit - DELETE

Database design

User:

• userId
• login
• password
• accessLevel

Account:

• accountId
• accountDetails
• [users]
• [parkingLots]

ParkingLot:

• lotId
• [spots]

Spot:

• spotId
• booking?
• type

Booking:

• bookingId
• car
• entry // used to estimate time parked and also usage analytics
• release // used to estimate time parked and also usage analytics

Car:

• licencePlate // primary key
• colour
• type
• frequentCustomer // Bool - used when booking frequently over a certain time unit. Allows us to offer discounts or even fixed car parks in the future.

We will use a NOSQL db type to allow for higher scalability if the product takes off or bigger parking lots enter the market.

High-level design

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

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

Using an internal API to distribute parking lot data for account and bookings, can be slower sometimes, but it will save a huge amount of queries to all databases. It will take a bit more when fetching account details, but no need for higher availability here. For bookings, it will take a bit more time when creating the booking, but then the cache will handle further booking changes asap.

Using a cache for bookings for maximum availability of booking records. This allows parking spot availability to be updated asap when cars come and go.

A bookings updater that will asynchronously store the historical record of each booking. Also storing car data in to their database to later on scale product offering for returning customers.

Failure scenarios/bottlenecks

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

Future improvements

• Implementing a payment processing service to charge for bookings
• Adding contact details to the car record so we can implement notifications and offers.