System requirements

Functional:

• AllocateLot
  • Allocate the Parking Spot based on Vehicle type
  • With the duration available for time
  • if there is no spot, we can response with there is no spot
  • return ticket id
• ReleaseSpot
  • Release the Spot based on the ticket id
  • there should be payment processing for the based on the duration
  • if ticket id is invalid -> return failed to find the ticket instance
• NotifyUser
  • Notify user before 30 minutes

Non-Functional:

• Strong consistency
• Strong Availabilty
• Low Latency

Capacity estimation

Estimate the scale of the system you are going to design...

DAU : 5000

each Spot Query Size : 100B

There is 5000 of spots

Storage Expectation : 100B * 5000

API design

Define what APIs are expected from the system...

/api/allocate

ReqBody :

{

Vehicle Type

Time Duration

}

ResBody :

{

Ticket ID

Expiration Date

Expected Fee

}

//if invalid or no free spot -> response with failed to allocate

//Success : 200

//Failed By Client : 400

/api/release

ReqBody :

{

ticket ID

}

ResBody :

{

Fee Charged

}

//if ticket not found -> response with failed to process

// Success : 200

// Failed By Client : 400

Database design

Ticket

• Ticket ID
• Spot ID
• Device ID
• Created By
• Expired By
• Expected Fee

Spot

• Spot ID
• IsAvailable
• VehicleType

Device (User)

• Device ID
• Device IP address

High-level design

Client goes to App server for request and there should be database processing the request and return the response

We will use DB as RDBMS because it is good to use if there is relations between the data.

There can be multiple server as horizontal scaling with load balancer.

Request flows

Allocate Spot

• It goes from client to server
• Server find free spots with vehicle id and duration
• if there is no spot -> response with failed to find spot
• If there is spot -> change spot status to be allocated to be true and generates the ticket with time stamp and time duration

Release Spot

• It goes from client to server
• Server find the ticket and process the payment based on the information from ticket
• and return the charged Fee
• Also make the spot to be free(make isAllocated to be false)
• Remove the ticket instance from the DB

Notification Service

• Query Scans the DB and find tickets with less than 30 minutes left from expiration date
• notify to the user using messaging queue to notification service.

Detailed component design

Application server will handle internally to find free spots for specific vehicle type

Also Application Server takes all the tickets which have 30 min left from expiration dates and send it to messaging queue to send notification to device (user)

After release the spot, process the purchase the charged fee through external API (we can use stripe or Square for it)

Trade offs/Tech choices

I used RDBMS for storing ticket and spot and device metadata because they have relations between them. I use messaging queue which is able to handle large set of request to services asynchronously.

Failure scenarios/bottlenecks

If we use load balancer to handle request to multiple servers, it can be single point of failure. Because Database and server continuously handles the expiration dates to send notification, it can be bottleneck.

Future improvements

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

We can use multiple LB to prevent single point of failure. Database can be sharding using consistent hashing. We can implement feature of user to make over durated parking lot charge. To improve security, it is also good to implement authentication and authorization system.