System requirements

Functional:

Princing:

1. Pay as you go - hourly rates in minute increments
2. Daily rates - per day rates
3. Monthly - per month rates

Parking space types:

1. standard
2. motorcycle
3. electric vehicle

What the User can do:

• Buy ticket at the gate
• Reserve/Pay online
• No-show fee - in the case of tickets bought online if the user does not show up 30 minutes after the reservation, we charge a fee equivalent to 2 hrs

Infrastructure:

1. hosted backend
2. pay booth - handles payments via provider
3. gate computer - each gate has a computer has a physical link to the server on premise
4. digital display for available parking spots

How the system works:

1. Pay as you go - hourly rates
2. Get ticket at gate

• customer arrives at the gate, they press on the button to get a ticket and the following happens:
• system calls API with new ticket creation
• built-in camera appends the plate number if visible
• ticket is released to customer
• once ready to leave, the customer can:
• pay at the paying machine, the system will calculate the time spent inside the parking lot and multiply the minutes by a fixed rate; once the transaction is approved, the system marks the ticket as payed and syncs it to the gate ( gives a max of 5 minutes for customer to exist)
• the customer can proceed to exit where either the camera will detect the plate or the customer will scan the QR code on the ticket or app

b. Get ticket online

• logged in customer with active payment method, books via app in advance, video camera at the gate will detect the plate number of the car for easy access (if plate is missing or obscured a reservation QR code can be scanned by the customer at the gate to access the facility)
• at exit time, the system calculates the total price, charges active payment method and allows exit

1. Daily rates and monthly rates - pay in advance

Similar to hourly with the difference that the customer needs to pay in advance the estimated time they want to park for

• In the scenario that the customer overstays their planned period, they can simply pay the remaining balance at the pay booth

Non-Functional:

• Security
• customer data should be encrypted to protect privacy
• Availability
• in case the internet is down, the ticket machine at the entrance can issue physical tickets and allow customers to pay at the pay booth;
• Usability
• system could be accompanied by an easy to use app that allow members to pay in advance
• once paid, video camera at the gate will detect the plate number of the car for easy access (if plate is missing or obscured a reservation QR code can be scanned by the customer at the gate to access the facility)

Capacity estimation

This system should cover about 400 parking spots which could easily end up in thousands or tens of thousands of operations per day

API design

Endpoints:

• create ticket
• pay ticket
• create/update user
• create/update payment method
• getAvailableParkingSpots

Database design

Ticket:

• id
• user_id -> nullable
• vehicle_id
• issued_at
• payed_at
• estimated_amount
• amount
• plate_number
• timestamps
• available parking spots
• vehicle_kind

User:

• id
• payment_methods
• timestamps
• vehicle_kind

PaymentMethod:

• id
• user_id
• is_preferred
• timestamp

Prices:

• id
• provider_id
• amount

High-level design

You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...

mobile client:

• minimalistic UI that shows the number of parking spots and gives option to buy in advance
• allows for adding payment method
• login/logout user

remove server:

src/

api/

client/

ticket/

createTicket

payTicket - dedicated endpoint for payment

validateTicket

user/

upsertUser

upsertPaymentMethod

auth/

loginUser

logoutUser

proxies/

payment_providers/

provider_proxy/

services/

payment_providers/

syncFromProviderService - syncs data related to payment transactions

ticket/

markOverstayTicketsService -> called from a job

validateTicketService

calculateTicketAmountService

upsertService

user/

upsertService

paymentMethod/

upsertService

deleteService

models/

ticket

user

vehicle

paymentMethod

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

Regular operation - pay as you go:

--- creating ticket ---

• upsertTicket(plate_number?: string, available_parking_spots: number, vehicle_kind: enum, ticket_id?: string, user_id?: ID,)
• Ticket::CreateService -> persists a new ticket in the database

--- paying ticket ---

• payTicket(ticket_id: ID)
• calculateTicketAmountService - amount (if ticket was prepaid, calculates amount if period was overstayed)
• payment_providers/provider_proxy.pay(id, amount)

--- at gate ---

• validateTicket(ticket_id: ID)
• validateTicketService

Detailed component design

CalculateTicketAmountService

• calculate amount based on the number of minutes the parking lot was occupied by a specific customer by looking at the ticket creating date and timestamp at the moment they are trying to pay and multiply that by the `per minute price`
• if the ticket was prepaid but overstayed, calculate the overstay by the same formula

Trade offs/Tech choices

Opted for a design that does not necessarily link tickets to users to maximize profit by allowing non signed in users to pay for tickets at the facility

At the same time, there can be a one to many relationship between User and Ticket for users how create an account and use the mobile app to transact

Failure scenarios/bottlenecks

One major failure scenario that can arise, is when there is no communication with the server is blocked; in this scenario, a more advanced on premise server that constantly syncs to the payment provider and database can be implemented

Future improvements

Implement ability to work offline, maybe by requiring a CC when getting the ticket at the gate; this way, the customer can still scan the ticket and a log of the exit time is kept which will later be synced with the backend