System requirements

Functional:

List functional requirements for the system (Ask interviewer if stuck)...

1. Keep track of available parking spots: The system needs to maintain real-time updates on the number of empty spots for different types of vehicles. Sometimes a rough estimation
2. Record entering time: Capture and store the timestamp when a vehicle enters the parking lot to track duration.
3. Identify available parking spots: Determine available spots based on the size of the vehicle upon entry.
4. Handle full parking lot: Provide a message when no parking spot is available, directing the user to exit.
5. Calculate parking fee: Calculate fees based on the duration a vehicle is parked in the lot.
6. Accept payment: Allow drivers to make payments using various methods upon exiting the parking lot.

Non-Functional:

List non-functional requirements for the system...

1. High availability: Ensure the system is operational and accessible at all times to avoid disruptions.
2. Secure payment system: Implement robust security measures to protect payment transactions and user data.
3. Data preservation: Store payment and vehicle entry/exit logs securely in a durable and reliable database for auditing and analysis purposes.
4. Monitoring metrics: Provide monitoring capabilities to track system performance, usage patterns, and parking lot occupancy.

Capacity estimation

Estimate the scale of the system you are going to design...

Assume we have:

600 compact car parking spots, 300 standard parking spots and 100 oversized vehicle parking spots.

Peak hour entry rate: 30 vehicles per hour

Peak hour exit rate: 30 vehicles per hour

Peak hour length: 2 hours

Off-peak hours entry rate: 10 vehicles per hour

Off-peak hours exit rate: 10 vehicles per hour

The parking lot operates for 12 hours per day.

That means 30 * 2 + 10 * 10 = 160 vehicles a day.

API design

Define what APIs are expected from the system...

enter(license: string, vehicle_size:enum) -> num_of_available_parking_spots, parking_record_id

vehicle_size could be COMPACT, STANDARD or OVERSIZED.

getParkingFee(parking_record_id: string)->fee:float

exit(parking_record_id: string)->leftFee:float

processPayment(parking_record_id: string, payment_id: string, payment_method: enum, card_info: object)

payment_method could be cash, debit or credit

Database design

Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...

PARKING SPOTS TABLE:

1. id: varchar (PK)
2. spot_type: varchar (compact, standard, oversized)
3. total_spots: integer
4. taken_spots: integer
5. updated_at: timestamp

VEHICLE PARKING RECORD TABLE:

1. id: varchar (PK)
2. license: varchar
3. enter_at: timeStamp
4. exit_at: timeStamp

PAYMENT RECORD TABLE:

1. id: varchar (PK)
2. vehicle_parking_record_id: varchar (FK)
3. fee: float
4. payment_method: varchar (cash, debit or credit)
5. card_info: object (metadata of the card used in payment)
6. external_payment_id: varchar
7. paid_at: timeStamp

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

This system contains following components:

Client - user-facing UI machines at entrances and exits of the Parking lot.

Server - The main business logic lives here.

Database - Holds table to track current number of available parking spots. As well as recent parking record and payment record.

External Payment System - a third party payment system that takes payment (e.g. square)

Cron machine - Running a cron job to obtain old records (probably records older than 1 year and stores them in cold storage), the records could be cleared up in Database.

Cold Storage - Low cost storage to store old record, as they're seldom accessed.

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

1. When a car arrives, the client sends an enterRequest to server with the vehicle's license number and its vehicle size. The server will querying the parking spots table and reads the available spots by total_spots - taken_spots. The server will then attempt to update the parking_spots table and increment the spots_taken field if the time_stamp did not change since last read. This is an optimistic locking. Since we have very low traffic in a parking lot, we can use this technique. In the same transaction, the server will need to insert a new record to the parking record table. However, if there is already a parking record with no exit timestamp for this license number, the transaction should be roll-back. The server then returns the number of available spots back to client. This number could be zero or negative, indicating that no spots is available.
2. When a driver trying to pay before left, the client sends a getParkingFeeRequest to the server. The server then querys the parking record table to get the entrance timestamp of this vehicle, calculate the fee, and returns it to the client.
3. After the payment is taken by a machine or an employee, the third party payment system should generate a unique payment id, the client sends a processPaymentRequest to server, the server querys the external payment system to validate the payment. If validation succeeded, the server inserts a new payment record in payment_record table, if there is not already one for this payment, and returns a response to the client.
4. When a driver is attempting to leave, the client sends an ExitRequest to the server. The server querys payment record table as well as parking record table. The server will then calculate the fee based on the parking record table, and compares that to the payment the driver has made. If records match, it updates the parking record table and the parking spot table in one transaction, if the parking record table didn't already have a timestamp. It returns the outstanding fee to the client, if the number is zero, it means all payments are cleared and the vehicle is good to go. Otherwise the driver will be asked to pay outstanding fees.

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

Cron machine & cold storage: The past parking records and payment records might be useful for future reference, audition, etc. However, it is not accessed very frequently, therefore, a cron job could be setup to run monthly and pull data that's over 1 year ago and store them in s3.

Server: we have very low traffic so 1 machine could handle all traffics. However, in order to ensure the availability of the service, we introdcue duplication in the server. We can have multiple (3 might be good enough) machines to serve the data. Whenever a client calls the service, it can use a round robin mechanism to choose a server to call.

Database: Similar to server, we are not expecting a huge number of data, and the data can fit in to one machine. However, in order to avoid downtime introduced by machine crashing or maintenence, we should introduce replica of the database. The database could run in master - slave mode, and the master is responsible to copy data over to slaves. In case the master machine is unavailable, a slave machine will then become the new master.

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

The cold storage is chosen over storing historical data in database for the following reasons.

1. Cold storage is generally cheap.
2. Database will grow with historical data, and eventually we will run into a situation where we need to scale up or scale out. Cold storage could help us avoid that complexity.

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

When a database machine is crashed, the service can make use of the replica machine.

When a server machine is crashed, we will have the following scenarios:

If a client is sending an enter request to a server but didn't get a response, it will send the request to a different server. The two servers might end up creating duplicate parking record and update the parking spots table twice. To avoid this, we can have the server update both tables in one transaction (will both succeed or fail). And in the same transaction, the server should first check if there is already a parking record for the same license number.

If a client is sending a getPayment request to a server and didn't get a response, it will just call a different one.

If a client is sending a processPayment request to a server and didn't get a response, it will call another server. As we have a unique payment id from third party payment system, this should not result in duplicate records.

If a client is sending an exit request to a server and didn't get a response, it will call another server. This might resulting in updating the database twice, therefore, the server should update the parking record and the parking spots table in a single transaction, under a condition where the parking record has no exit timestamp.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?

The system could potentially be updated to support multiple parking lots.