Design An Efficient Parking Lot System - System Design

System requirements

Functional:

handle payments
support for hourly, daily, and monthly reservations
standard, compact, and oversized vehicles have different rates
impose a limit of 2 vehicles per owner

Non-Functional:

https
scalable
highly-available

Capacity estimation

each garage has a capacity of 500 spots
1 parking spot per vehicle
turnover of 3 (each parking spot accomodates 3 vehicles per day) -> 500 * 3 = 1500 potential users per day
All 6 dbs combined (see db details below) account for ~2GB/year of persisted data
Since the schemas are fixed, the volume is very low, and transactional processing is necessary for at least 1 system (payment), a relational database management system may be used for all databases. That said, there is no need for joins, so every db except for the payment db could be implemented with NoSQL.

API design

userService - Handles user creation and login.
/create-user
PUT request with userId, password, email, address, and firstName and lastName in request body
Persists user account information (password is hashed)
Returns 200 OK on success, 400 Bad Request on failure (e.g., user already exists)
/login
POST request with userId and password in request body
Returns 200 OK and auth token on success, 400 Bad Request on failure (e.g., user does not exist or invalid password)
paymentService - handles registration of payment methods, balance requests, payment requests, and receipt requests
/register-payment-method
POST request with userId, accountNumber, routingCode in the request body
Registers a bank account for making payments via ACH (requires the bank account number and routing code)
Returns 200 OK on success, 403 Forbidden if the user is not logged in, 400 Bad Request on error
/register-payment-method
POST request with userId, nameOnCard, cardNumber, expirationMonth, expirationYear, securityCode in the request body
Registers credit/debit card for making payments
/check-balance?user-id=<userId>
GET request
Returns 200 OK and amount owed on success, 403 Forbidden if the user is not logged in, 400 Bad Request for invalid user
/make-payment
Post request with userId, paymentMethodId, and amount in the request body
Sends payment details to the Payment Message Queue for the external payment system to ingest.
Returns 200 OK and PENDING status on success, 404 Not Found if unable to emplace on queue for whatever reason, 400 Bad Request on invalid input
/get-receipt?user-id=<userId>&payment-id=<paymentId>
GET request
Returns 200 OK and receipt for the given payment id on success, 403 Forbidden if the user is not logged in, 400 Bad Request if userId or paymentId are invalid
/get-receipt?user-id=<userId>&start-time=<YYYYMMDD>&end-time=<YYYYMMDD>
GET request
Returns 200 OK and all receipts for all payment ids associated with the user between the start and end times, 403 Forbidden if the user is not logged in, 400 Bad Request if the userId or dates are invalid.
externalPaymentService
Retrieves payment requests from the Payment Request MQ and sends them to external payment systems for processing (details of external payment system interaction is out of scope for this design)
Emplaces the external payment systems' payment responses to Payment Response MQ
allocationService - registers vehicles, determines vehicle pricing, and checks in/out vehicles to the garage
/register-vehicle
PUT request with userId, vehicleMake, vehicleModel, vehicleYear, vehicleLicensePlate, and reservationType in request body
Returns 200 OK on success, 403 Forbidden if the user is not logged in, 400 Bad Request if the vehicle is already registered or any other invalid input.
/get-vehicle-rate?make=<vehicleMake>&model=<vehicleModel>&year=<YYYY>&rate-type=<'H' or 'D' or 'M'>)
GET request for retrieving current hourly, daily, or monthly rate for a particular type of vehicle.
Returns 200 OK and the rate on success, 400 Bad Request otherwise
/check-in-out?user-id=<userId>&vehicle-id=<vehicleId>&direction=<'I' or 'O'>
POST request
Returns 200 OK if the user is able to be checked in/out, 403 Forbidden if the user is not logged in, 400 Bad Request otherwise

Database design

User DB
schema: <userId VARCHAR(255), passwordHash CHAR(8), email VARCHAR(255), address VARCHAR(255), firstName VARCHAR(255), lastName VARCHAR(255)>
row size = (255 + 1) * 5 + 8 = 1288B
1500 users/day -> 1288 * 1500 = 1920000B = 1.92MB/day
1.92 * 365 = 700.8 MB/year
Payment DB
Bank Account Table:
schema: <bankAccountId INTEGER, userId VARCHAR(255), accountNumber VARCHAR(255), routingCode CHAR(9)>
row size = 4 + (255 + 1) * 2 + 2 = 518B
roughly half the size of user db per record, so assume 1MB/day, 365MB/year
Card Account Table:
schema: <cardAccountId INTEGER, userId VARCHAR(255), nameOnCard VARCHAR(255), expirationMonth CHAR(2), expirationYear(4), securityCode VARCHAR(4)>
row size = 4 + (255 + 1) * 2 + 2 + 4 + 4 + 1 = 527B
roughly same size of Bank Account Table, ~1MB/day, 365MB/year
Payment Status Table:
schema: <userId VARCHAR(255), recurringBalance DECIMAL, currentBalance DECIMAL, nextRequiredPaymentDate TIMESTAMP>
row size = 255 + 1 + 8 + 8 + 8 = 280B
roughly 2/3 size of Payment Account Tables, so estimate ~700KB/day, 255.5MB/year
Allocation DB
Vehicle Table:
schema: <vehicleId INTEGER, userId VARCHAR(255), make VARCHAR(255), model VARCHAR(255), year CHAR(4), licensePlate VARCHAR(16), registrationType CHAR(1), inOut CHAR(1)>
row size = 8 + (255 + 1) * 3 + 4 + 16 + 1 + 1 + 1 = 799B
Expect 1 vehicle/user = 798*1500 =~ 1.2MB/daily =~437MB/year
Vehicle Rate:
schema: <make VARCHAR(255), model VARCHAR(255), year CHAR(4), hourlyRate DECIMAL, dailyRate DECIMAL, monthlyRate DECIMAL>
row size = (255 + 1) * 2 + 4 + 8 + 8 + 8 = 540B
roughly 1MB/day, 365MB/year

High-level design

userService - Handles user creation and login.
paymentService - handles registration of payment methods, balance requests, payment requests, and receipt requests.
externalPaymentService - handles processing of payment requests received from the paymentService with the actual external third-party payment systems.
allocationService - registers vehicles, determines vehicle pricing, and checks in/out vehicles to the garage.

flowchart TD

user[User] --> api_gateway{API Gateway}

api_gateway <--> user_service[User Service]

user_service <--> user_db[(User DB)]

api_gateway --> payment_service[Payment Service]

payment_service <--> |writes|payment_db_master[(Payment DB Master)]

payment_db_master --> payment_db_replica[(Payment DB Replica)]

payment_service <--> |reads|payment_db_replica

payment_service --> payment_request_mq[/Payment Request MQ/]

payment_request_mq --> external_payment_service[External Payment Service]

external_payment_service --> payment_response_mq[/Payment Response MQ/]

payment_response_mq --> payment_service

external_payment_service <-...-> external_payment_system[External Payment Systems]

api_gateway --> allocation_service[Allocation Service]

allocation_service <--> |writes|allocation_service_db[(Allocation DB Master)]

allocation_service <--> |reads|allocation_service_db_replica[(Allocation DB Replica)]

allocation_service_db --> allocation_service_db_replica

allocation_service <--> |Check payment status|payment_service

Request flows

UserService: creat

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

Trade offs/Tech choices

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

Failure scenarios/bottlenecks

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

Future improvements

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