Requirements

Functional Requirements:

• Allow reservation of a parking spot.
• Process payment for the reservation.
• Enable parking of a car in the reserved spot.
• Support early departure before reservation time expires.
• Gate check-in/out.
• Handle no show.

Non-Functional Requirements:

• List the key non-functional requirements (eg low latency, scalability, reliability, etc.)...
• Strong Consistency (Double booking would be bad)
• High availability (Need to allow gate check out...may even want a local override)
• Scales with added parking lots

API Design

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...

Objects: User, Lot, Reservation, ParkingEvent

`/users/`

`/lots/`

`/reservations/`

`/parking-events/`

Users register themselves

Lots are created by admins

Reservations are made by users

Parking Events are recorded as they occur (check-in/check-out)

High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.

Separate UIWorkflow from API layer in order to keep API layer simple/agnostic of UI concerns.

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.

Reservations

start_time

end_time

user_id

lot_id

payment_id

Payments

Payments are handled by an outside system via the UIWorkflow system.

Gates

The Parking Lot Server will need to communicate with the Gates at each lot in order for them to know that one of our users is parking there. The gates will need to query the parking lot server to determine whether a user can park or not so that it can open the gate to the lot for the car. It will also need to inform the parking lot server when the user checked in and checked out.

Reservations require finding a time window where the lot has sufficient capacity. Reservations can fail between time user requests reservation and time the database attempts to commit due to async reservations consuming all capacity in a lot.

Finalizing the reservation flow is making a payment for it.

The system should book the reservation and reduce the capacity of the lot before attempting the payment in case the capacity is exceeded while the payment is outstanding. If the payment fails, the reservation is removed, opening up the capacity again.

Early Checkout, No-Show or Extended Parking

We want to record Parking Events directly from the gates so that we can reconcile the reservation times/payments/costs with what actually occurred. When there is a discrepancy, we can handle refunds or collections as a separate effort.