System requirements

Functional:

• As a user, I want to know if the parking lot has free spaces or how many
• As a user, I want to get a parking entry ticket for a certain time window
• As a user, I want to be able to exit the parking lot
• As a user, need an interface to pay the fine if I overstay

Non-Functional:

• The system needs to be durable and favour consistency over availability
• The ticket printing/processing (on exit) needs to be done within 1 second
• We need to accommodate 500 vehicles

Capacity estimation

With 500 maximum vehicles parking at any time, the capacity isn't very large. If a car is parked for 1 hour on average, then there can be at most 24 * 500 = 12000 entries and exits per day. There are 86400 seconds in a day, which means the entry and exit QPS is roughly 0.14 QPS.

In terms of storage, we can for now assume that at the very basic level, we will need to store the plate number of each car, and we will at most store 500 plate numbers.

API design

• Get parking lot spaces:

GET /parking/spaces

• Print a ticket upon entry, with the body containing the time window selection, default being 1 hour. Also, the body will contain the plate number of the car entered by the user:

POST /parking/ticket

body {

timeWindow: number,

carPlate: String

}

• Exit the parking lot

PUT /parking/exit

body {

ticketId: id

}

Database design

The main components will be:

• Parking Lot
• Ticket
• Car Information

I can store all of this information in a SQL database. The schema and data that we need is predictable, hence Relational DB is a good option.

High-level design

Request flows

• When the client arrives at the parking lot entry, the system will make a get request to find out how many free parking spaces are available. For that, the parking system will query the `parkingLot` table which will have a field associated with it that gets incremented/decremented each time a car exits and enters the parking lot
• When printing the parking ticket, the parking system take the provided time window configuration and save it in the database by creating a new ticket. It will also timestamp the date time YYYY-MM-DD HH:MM, to keep track of the vehicle entry.
• Upon exit, the parking system will read the ticket's car plate number and check the database for the entry timestamp. If the difference between current timestamp and entry timestamp is greater than the configured time window, then a charge will be applied, for example, any extra hour stayed costs 1 additional dollar. If the time window selected was just 1 hour and the user does not exceed that, then the user can simply go. Otherwise, the user will have to pay any charges associated with the selected time window and potential overstay
• To handle the payments, the client upon exit request and calculating the charges, will show them to the user. When the user confirms the receipt, another call will be made to the parking system with the callback url. this callback will be sent to a payment provider system, e.g. Stripe, to initiate the payment process on the client side by using the callback URL. Once the payment is done, the payment provider will notify of payment success the Parking system, and the parking system can update the database with marking the ticket as paid, as well as incrementing the number of available spaces in the parking lot.

Detailed component design

Currently the system is prone to data loss since it's a single server and a single DB component

We can scale horizontally the parking system to have multiple servers running for redundancy in case a server goes down. In order for the client to know which server to make a call to, we can introduce load balancer layer which will keep track of running servers and will spin up a new instance if a server goes down.

Additionally, the database is also a single point of failure, so I want to have the database replicated multiple times, say 5 times, to ensure fault tolerance of data.

The system cannot tolerate loss of car plates at any point, so we will want to have each request be a transaction and abort on failure and ask the user to retry. Each request write request will write to all 5 replicas within the same transaction to ensure full consistency.

Trade offs/Tech choices

Failure scenarios/bottlenecks

Future improvements