System requirements
Functional:
User can pay for entry and exit
Different size spots -> small, medium, large
Different cost for each -> cost increases with size
Non-Functional:
Aiming for consistency and availability
Capacity estimation
50 * 10000 -> 500000 parking lots
5 transactions per second
API design
Public Endpoints:
Send in license plate and picked spot in body of request
User just needs to input license, parking spot and hours
/Parking -> send request to pay for spot
Private Endpoints:
Send in spot size and hours
/Calculate
Database design
Relational
MySQL
Users Table:
UserID VARCHAR(15)
First Name VARCHAR(25)
Last Name VARCHAR(25)
16+26+26 -> 68 bytes
Parking Spots Table:
LotID VARCHAR(15)
Spot Number INT
Size INT
Occupied DateTime
16+4+4+5 -> 29 bytes
Reference Table for size:cost
High-level design
User can book a spot, pay for amount (hour*rate)
Spot's rate depends on size of spot
Request flows
Client side send request
if spot is available then success
if spot is in use, but with same license plate, extend time then success
if spot is in use, but with diff license plate, then failure
Request gets sent to api gateway (rate limiting, authentication, authorization, can use AWS)
Request gets sent to load balancer
Load balancer sends request to server
Server will try to process payment (third party)
Server will update DB
Response depends on success of DB transaction
Server sends response back to user
Will use third party paying app such as Stripe/Visa
If payment succeeds then try to update DB and then send a success response
Detailed component design
/Calculate endpoint:
Grab spot size from request body
Grab duration from request body
Calculate price by grabbing rate from Size:Rate relational table
rate * duration to find cost
/Parking endpoint:
if Occupied column > current time:
check license plate, if matching with request then extend else reject transaction
Trade offs/Tech choices
MySQL, relational database because the rows of parking spots have a tight relationship, so do rows in User table
Visa/Stripe as payment methods because most users have access to these payment methods, third party payments should have their own retry mechanisms
Consistent and Available, because we need to know when spots are taken, and always want user to be able to pay
Failure scenarios/bottlenecks
Spikes of ppl paying during certain times, for example if a lot of ppl paying in morning when they are going to work
solution -> shard database by region or shard database by parking lot ID if we need to scale
Future improvements
Have map of available spots, that would mean an increase in reads, may need to use replicas
can ask for user recommendations