System requirements

Functional:

Main

Parking Space allocation by vehicle type

Payment processing for parking space time

Must be able to serve, long term as well as short time clients

Secondary

Security

Tracking exits, and entries

Non-Functional:

Availability of in parking lot systems

Cars must be able to exit always

Payments and entrances should be up to guarantee income

Easiness of use

Constant throughput of cars, so there's no congestions in exits and entrances.

Capacity estimation

The system I'm going to design will able to support a parking lot with a total capacity of 400 cars.

This means that at peak time, up to 200 cars could be going in and out.

API design

ReserveLongTimeParkingSpot:

input: plate number and time to stay

Output: activates a spot

PayParkingSpot

input: PaymentDetails and parkingSpot reservation

output: boolean confirmation

RequestEntrance

input: plate number

Output: ticket or boolean (for long term users)

Exit

input: plate number

Output: None

Database design

For data models we will have:

Reservations:

Id

Time to stay

Car type

License Plate

Payments:

Id

ReservationId

Time

Status

Entries and exits:

License Plate

Timestamp

High-level design

For the payment systems there are two kinds, phone app and physical payment machines.

For the parking lot, lots of exits and spaces for the different types of vehicles considering size, maneuverability and electric or not

Regarding physical infrastructure

Local backup power for reliability

Local server for coordinating local infra, optimizing space usage and keeping track of capacity to avoid overselling.

Wifi access for easy phone payment

Color light bulbs on top of the parking places to indicate which one to use, or which one is over time or abandoned.

License plate cameras and automated entries with manual override.

Display to show if there's space or not.

Request flows

A new customer arrives and requestsEntry, his license plate is scanned. He receives a ticket if needed or is let pass if its a long term client, as this has been checked by the local service in the local server.

Light bulbs indicate the parking spot for the person using a special color, the user is guided with the lightbulbs as well, this is secondary UX though.

Customers reserve spots for long term stay, in the phone app whether connected or far outside and pay after reserving. The reservation expires if payment is not done in time but prevents double booking.

If there's no space in the parking lot it is displayed on the outside.

Entries and exits are logged and the presence or absence of a car is tracked.

Detailed component design

A master coordination service keeps track of capacity, spaces used and cars that are in, as well as coordinate the lightbulb guiding and showing the spots.

The reservations app is online so it can be reserved from outside the place, its a web server. If needed a physicalpayments machine can be used.

Tracking and space allocation is done in a program taking into account time, day, tendencies, and allocating for long serve users. Patterns are underused, which means we are conservative about how we profit from the efficiencies to have availability under change, like over-profiting from regular habits of long term tenants, could leave them without a spot during a fluctuation.

For operation during power shortages, local infrastructure both physical and the backup power generator, keep payments, exits, and entries up. During power shortage we minimize consumption, so no light bulbs and backup to physical infrastructure. We keep the reservations locally so long time tenants can access and exit.

Trade offs/Tech choices

Manual tickets and pay after you enter but before you leave is essential to keep throughput in entries and exits, as well as reliability in exchange for some usability.

The additional web service for payments adds complexity, keeping a second system while enabling selling outside of the parking lot and offloading physical infrastructure.

The colored lightbulbs add a lot of complexity, particularly with the guidance, in exchange to increased usability, and a better user experience as well. Also without these we wouldnt' be able to profit from our space optimizations as clients might park anywhere, which would also impact convenience of entering and exiting. We do not optimize for collisions and short paths, we just prevent deadlocks.

Failure scenarios/bottlenecks

Power shortages are handled by the backup power and the change in operation mode, as well as the physical tickets and local payment machines.

Double booking is avoided by reserving before entering and optimizing space, as well as checking before allowing entry and announcing space availability.

Due to physical limitations of car entry and reservation, capacity estimation and allocation is simple.

The online app service was not detailed and could be overfilled, but as its for long time tenants whose usage is expected to be limited its not a problem.

If a car goes in and there are no spaces left, and the entrance is saturated by entries we can let it enter and exit through another gate

Future improvements

Subsituting complex path guidance and lightbulb guiding, as well as space optimizations for a simpler combination and solution might be good, for cost, implementation and replication on other places.