Calculation for User Table:
Assuming first names and last names are 10 characters each
Assuming Payment information is 12 characters each
Assuming UserID is base64 encoded -> 6 bytes
Every row would be 38 bytes
38 * 1000 = 38 000 bytes -> 38 KB per day
Calculation for Parkade Table:
Assuming UserID is base64 encoded -> 6 bytes
Parking spot -> 4 bytes
License Plate -> 6 bytes
Type -> 1 byte
Exipry Time -> 5 bytes
22 * 10 000 -> 220 000 bytes -> 220 kb
Calculations for Parking Spots Table:
ParkingID -> 4 bytes
Type -> 1 bytes
Available -> 1 byte
External:
POST:
GET:
GET:
Internal:
GET:
Because each table's row has a structure that has clear relationships with each other, we will use SQL
User Table:
Parkade Table:
Parking Spots Reference Table:
Price Per Hour:
Parking spot reference table has parking type for each spot
Application code can contain reference to price for each type and do something like NumberOfHours*price[Type]
Parking Expiry:
Application code will add the number of minutes the user wants to park for and add to current date time (add extra 1 minute in case of any lag) and then udpate Parkade Table with expiry time
Explain any trade offs you have made and why you made certain tech choices...
Bottle neck could be if there are too many people trying to see when their parking expires
-> Use DB replicas -> This case synchronous because we want to be sure to only allow user to pay for spots that are available, its okay if they have to wait a second or two to grab this information, the tradeoff is worth it
Bottle neck could be if theres too many people trying to pay at once
-> Shard the database to alleviate too many writes to a single DB
-> But in this case because theres only 1000, this shouldnt be an issue
Possibly if payment fails but because we are using a third party app, they should probably already be handling retries but we can still retry request to third party app if the payment fails
Depending on what users are looking for, we can build new features