System requirements

Functional:

The User can check in during entry and get a spot assignment

The User can check out and pay for parking

Non-Functional:

The System never assigns a filled spot to a user

The System keeps track of all customer's time in the parking lot

The System Is Highly available

The System Is fault-tolerant

Capacity estimation

Parking lot systems are normally low traffic compare to other large systems to let's say out parking lot is able to hold 500 cars and on average each car is in the parking lot 4 hours so even if the parking lot is busy 24hours a day we would have 6*500 transactions = 3000 total transactions.

Let's say we keep track of all cars data for up to 1 year so we will have

400 * 3000 = 1200000 entries. let's say each entry has photo of the car , spot assignment and metadata of the transaction and that data on average takes about 1 MB. so we will need

12 * 10^6 * 1 MB = 12 * 10^6 MB = 12 TB

Since transactions on average are low we can get away with no cache but let's say if we do decide of have one we can have a cache of size 3 GB will be able to keep all data for the day.

This can be an in-memory cache on the machine that is serving.

API design

CheckIn( String Car_platenumber) -> number spot assingment

Get_balance(String Car_plageNumver) -> Int customer account balance

Pay_balance(String Car_plateNumber) -> returns secure payment link

Database design

Database can be fairly simple here since the data is very structured and we need to make sure that we never assign the same spot to two people we need all instance of the database to update simultaneously even if we decide to use same systems in multiple parking lots. So We can use MySQL for this.

For caching purposes, we can use a write-through cache. And since we can probably keep all the daily data in the cache, we can implement a custom eviction policy where the every be removed once the customer completes the transaction.

High-level design

For the high level design would be as follows:

Customer -> Application -> cache -> DB

the customer goes to the application and checks in, the application updates the cache and DB and gives the customer the spot number. During checkout the application checks cache for the customer info, initiates a payment transaction and if that is successful it removes the entry from cache and moves it out of a DB to an archival storage or a small OLAP database for query the data for analytics.

Request flows

Detailed component design

Trade offs/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?