System requirements

Functional:

The system should allow:

• requesting a parking space for a vehicles of different types
• paying for a space on exiting the parking lot
• reserving a parking space in advance

Non-Functional:

The system should handle

• simultaneous requests correctly
• situations when there's no free spaces left
• handling failures and emergencies

Capacity estimation

If it's possible, we can have the system to be able to accommodate up to 200 vehicles, so we can cover rush hours easily.

API design

We need to support the following types of requests:

• POST /spots/reserve?vehicle=<vehicle-type>&from=<timestamp> returns an id a reservation for an entering vehicle
• POST /reservations/{id}/enter - returns a parking spot identifier
• GET /reservations/{id}/price returns current outstanding amount for a specific parking spot
• POST /reservations/{id}/pay
• POST /reservations/{id}/exit

Database design

Since we have several main business entities here like Reservation and Spot, which relate to each other in particular way. And since we would want to effectively query and connect those entities SQL (like PostgreSQL) database seems like a good choice here.

Reservations database stores records for reservations made by clients with the following fields:

• id: String - reservation identifier
• vehicle_type: Enum(3) - identifier of a vehicle type
• spot: String? - identifier of assigned spot, default = null
• entered: Date? - timestamp of the vehicle's entering moment, default = null
• payment: Long - parking price payed
• exited: Date? - timestamp of the vehicle's exiting moment, default = null

Spot database:

• id: String - parking spot identifier
• vehicle_type: Enum(3)

High-level design

We have several main components in the system:

• Client - web or mobile application
• Load balancer and rate limiter
• Reservations service - service responsible for creating/updating/deleting reservations
• Entrance service - service responsible for entering/exiting the parking lot
• Reservations DB - storage for reservations

Request flows

First a client request a new reservation from the system. Then the client requests opening the gate with a reservation id, gets a parking spot id and parks the vehicle. When the client wants to leave it first sends a payment request with a reservation id and then requests opening the gates again with an identifier of the payed reservation and leaves.

Detailed component design

Reservation service will need to use some smart mechanism to assign a parking spot based on a current load and a requested vehicle type. We can use a bin packing algorithm to do it efficiently.

Trade offs/Tech choices

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

Failure scenarios/bottlenecks

• first we may encounter a situation when we cannot reach the entrance service, so clients cannot enter or exit the premises. In that case we firstly scale the service horizontally so that we don't have a single point of failure and, secondly, have an manual override, so no clients end up trapped in the parking lot
• if we don't book a parking spot in advance at the moment of creating a reservation we may encounter a situation where there are no free parking spots at the moment, when the client arrives. In that case we may offer a discounts or apply some statistical model for minimising the risk

Future improvements

We may want to offer dynamic prices to better adopt to rush hours and intervals of low demand. Or we can make our spot finding algorithm more flexible, teaching it to combine smaller parking spots into one spot for a bigger vehicle, if necessary.