System requirements

Functional:

• System should say how many spaces are available
• System will issue a slip on entry
• System will require payment and slip on exit
• System will have a "break-glass" option that allows exiting but takes a snapshot of license plate
• System will not allow in and out
• System will allow paying at exit or at kiosk
• System will allow preordering spots
• System will enable parking for multiple days

Non-Functional:

* System should be consistent

* NoReservation parking will be limited to a day

Capacity estimation

• 1000 spots * 5 usages a day = 5000

API design

• getSpotCount() -> int
• takeSpotDriveIn() -> Slip
• takeSpotReserved(ReservationSlip) -> boolean
• breakGlass() -> void
• exitDriveIn(Slip, Payment) -> boolean
• exitReserved(ReservationSlip) -> boolean
• getAvailability(StartTime, EndTime) -> Availability
• reserveSpots(StartTime, EndTime, Payment) -> ReservationSlip

Database design

* To model this, we would have a database (type TBD) where each time segment would be modeled with a row. We would need a Job that creates new entries when they are reservable.

High-level design

We will have a unified backend with multiple surfaces. We will likely need a transformer for each surface. We will have a SlotAllocationJob that invokes the Backend API to allocate slots on some cadence.

Request flows

* Car checks in on demand without a reservation -> Car goes to Kiosk and sees if there are any spots available, if there are, then they reserve a spot effectively for the day.

* Person wants to reserve a spot -> Person goes on app or website to check for available spots, and reserves one if available

* Car checks in with a reservation -> We verify reservation

* Car wants to leave with a slip -> Car enters slip and payment at Kiosk

* Car wants to leave without a slip -> Car hits "break glass" and a picture of license plate is taken and we send a bill. Car can also go to Kiosk and pay max day payment.

* Car wants to leave with a Reservation -> We accept reservation

Detailed component design

* The backend seems likely a relatively simple CRUD so we could start with a monolith. Probably use AWS API Gateway over an AWS Fargate or ECS instance.

* The database can be NoSQL. I see no need for a relational DB here. NoSQL enables using Dynamo which I like a lot.

* SlotAllocationJob would be some scheduled service, e.g. an AWS Lambda driven by a Cloudwatch Events or Eventbridge that invokes the API. If it starts to fail, we can alarm. It would call and allocate slots the next month or so. We could have two different portions here, job that generates messages (permutations) and then another job that invokes the backend API. To prevent impact when allocating we could throttle the call.

* Transformers I would probably model with AWS API Gateway over a AWS Fargate or ECS instance. This ensures minimal latency from cold start problem.

Trade offs/Tech choices

* The SlotAllocationJob could hit some scaling limits. We could explore a more complex slot free algorithm.

* The query operation on the Database could take some time, we could explore having an elasticsearch cluster to drive queries at the risk of eventual consistency.

Failure scenarios/bottlenecks

* An excessive amount of slots to allocate that browns out the backend/database

Future improvements

* Tech to support telling you where spots are or where to park. Requires some hardware sensors (e.g. camera)