System requirements

Functional:

• Allow user to pay for parking for x hours
• Allow user to cancel
• Small, medium, large cars have different rates

Non-Functional:

• Available
• Highly consistent

Capacity estimation

• 3000000 concurrent requests
• 8 Bytes per license plate (CHAR)
• 8 Bytes per userID (CHAR)
• 9 Bytes per DateTime
• 1 Bytes per type
• 26 Bytes per row
• 50 million requests a day -> 1.3GB per day for parked table

API design

External:

• /pay -> User tries to pay for spot
• Inputs: stall number, user, time

Internal:

• /calculatePrice -> Calculate price for stall (depends on spot size)
• car type, time

Database design

User Table (NoSQL):

User ID

• License Plates
• License Plate A
• Car Type A
• License Plate B
• Car Type B

Prices Table (NoSQL):

• Rates for car type

Parked Cars Table (SQL):

UserID(PK)

LicensePlate(VARCHAR)

UserID(VARCHAR)

ParkingExpiry(DateTime)

Type(CHAR)

High-level design

Client sends request

Serverside tries to pay through third party platform

Updates DB if pay goes through

Send response to let user know if payment was succesful

Request flows

Clientside -> Serverside -> Calculate Payment -> Third party payment -> DB (if payment sucessful) -> Clientside

Detailed component design

/calculatePrice -> hours * rate

Trade offs/Tech choices

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

Failure scenarios/bottlenecks

Too many requests at a time

• Loadbalancer

Too many writes to DB at a time

• Shard the database by area

Future improvements

We can check if the stall is already taken.

Right now we're not checking because its very likely that the user needs to park in the stall BEFORE paying therefore the user will probably not pay for a stall thats already taken.