System requirements

Functional:

• Number of parking lots

Non-Functional:

• System should always be available
• Shard ParkedCars DB by region
• Could shard Rate Database

Capacity estimation

• 300 requests at a time

API design

External:

• Post (/pay) -> take in license plate, type, time

Internal:

• Get (/getPrice) -> take in type, time -> Generate price
• Post (/sendPayment) -> Third party

Database design

Parked Cars:

LicensePlate (PK)

Time (DateTime)

Rates:

ID (FK from Place, PK)

Rate (Float)

Places:

PlaceID (PK)

High-level design

User selects type if there is type

Client side sends information to calculate price

Once third Part App goes through succesfully, we would update parked Cars

Request flows

/getPrice -> Send info to clientside to show price

/pay -> User attempts to pay

/sendPayment -> Attempt to pay through third party

Detailed component design

Serverside would calculate price and send to clientside

Clientside pays

Serverside pay through internal endpoint using third party

Once third party payment app is succesful, we update ParkedCars's time to be (currentTime+paid_hours)

Trade offs/Tech choices

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

Failure scenarios/bottlenecks

Failure in third party -> Retry

Future improvements

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