System requirements

Functional:

List functional requirements for the system (Ask the chat bot for hints if stuck.)...

Entrance/Exit Service: to track availability

Contactless Payment Service: Users can make payment easily through an online payment portal

Security Service: A monitoring service equipped with senors to protect cars and users.

Parking Allocation Service: Responsible for assigning empty spaces and updating the registry of availability.

Mobile App/User Interface: An easy to use GUI which will allow users to pay, book and see in real-time availability.

Non-Functional:

List non-functional requirements for the system...

Security

High Availability

Usability

Maintainability

Capacity estimation

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

3 parking lot systems, 500 spaces each, 1500 spaces total with a turn over rate of 5 spots per day. This gives us 4500 potential users where the GUI could use around 200MB for each user. 450000 * 2 = 900000MB. Around 1 GB for users.

10 cameras per system = 30 cameras at around 1GB per day with a 2 month holding period = 30GB * 60 = 300 * 6 = 1.8TB

API design

Define what APIs are expected from the system...

https://getParkingSpots/locationID

• parkingIDs
• availble
• timestamp

https://getParkingSpot/locationID/parkingID

• locationID
• parkingID
• availble
• timestamp

https://startPayment/locationID

• location id
• full name
• email
• address
• parking id
• timestamp

https://postPayment/locationID

• location_id
• full name
• email
• address
• parking_id
• timestamp
• payment_type
• payment_amount: string
• payment token id

https://getTotalParkinglotCapacity/locationID

• parking_lot_capacity
• location_id
• timestamp

https://getSecurityCameras/locationID

• timestamp
• location id
• media

https://getSecurityCamera/locationID/cameraID

• timestamp
• location id
• media

https://login

https://signup

Database design

Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...

Users Table

• user_id: string
• address: string
• full_name: string
• date_joined: string
• email: string
• index: user_id

Payment Table

• user_id: string
• payment_token_id: string
• timestamp: string
• payment_type: string
• payment_amount: string
• parking_lot_location_id: string

Parking Lot Table

• total_capacity: number
• current_capacity: number
• parking_space_id: string
• parking_space_available: boolean
• parking_lot_location_id: string

Security Camera Table

• parking_lot_location_id: string
• camera_id: string
• media_url: string
• timestamp: string

High-level design

You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...

Request flows

Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...

The User:

• Client opens up the user interface which is an app.
• A request is sent to the Load Balancer which routes it to an open API Gateway.
• The API Gateway Authenticates ths user and lets them into the user interface.
• The user requests to see if they can allocate a parking spot.
• Ther user interface routes the client to the the approriate service.
• The load balancer accepts the request and routes it using a round robin algorithm to the approriate queue.
• The parking allocation service notifies queue 3 that it is ready for it's next request.
• Queue 3 routes the client to the parking allocation service.
• The parking allocation service allows the request to go through since it has capacity and notifies the write DB.
• The request is sent back to the user interface.
• The user parks their car and then requests to start payment.
• Similar to above the request goes to the Start payment service.
• The payment service communicates with Paypal to initiate a payment and to get a payment token.
• The payment token is returned to the user interface and send to the write database base.
• The user starts the post payment.
• Similar to above the request is sent to the payment service.
• The payment service communicates with paypal to post the payment and then sends the details back to the user interface and to the sql write DB.

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

Load Balancer

• The load balancer before the API Gateway is a hardware load balancer and is primarily used to route http/https traffic

• The load balancer before the Three Queue's is a software balancer that lives in a virtual machine.

• The load balancers help distribute traffic evenly among API Gateways and the three queues which are for the security, parking/allocation and payments services.

• Load balancers help us provide high availability by ensuring one service is not overloaded with too many requests.

• Since All of our services and API Gateways have the same amount of CPU and memory processing power the algorithm we choose to use for load balancing is Round Robin. The round robin algorithm routes information in an infinite loop to each service and then goes back to the top of the loop and routes the information again. So if we have 6 requests, service 1 gets the 1&4 request, service 2 gets the 2&5 request and service 3 gets the 3&6 request.

API Gateway

• The API gateway handles all of the authentication in one place. It checks the headers and ip addresses to ensure we only allow addresses based in the United States. 

• We also implement a Rate Limter in the API Gateway. The rate limiter is implemented by tracking the ip address of the request in a map and blocking more than 5 requests within a 10 minute threshhold. The rate limiter helps ensure we're highly available and secure by helping to block Denial of Service attacks, those attacks could take down our service and compromise sensitive user information. 

• We also have a whitelist of IP addresses that are automatically blocked if they're in this list. This is all done in the API Gateway.

• The API Gateway is also where we collect logs for monitoring purposes. We collect all vital data we need to ensure our system is highly available and easily maintainable. For example, multiple heart beats for various services are implemented throughout our system to ensure the services are still up and running. This information is tracked and logged in the API Gateway.

Trade offs/Tech choices

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

• We chose the round robin algorithm for our load balancer since it's easy to setup and all of our current servers and cpus have the same processing power, however we understand that once we scale up this may have to change at some point since servers come and go and this would be harder to maintain in the future.
• We use One write Database which is the single leader and two follower read databases. Since our user and parking lot tables are somewhat manageable, we choose this strategy since it's not complicated to setup. We also choose it because it has strong consistency and data integrity. We understand that this can affect performance in the future since if we scale up, one write database will not be able to handle all requests in every region across the world.

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

We may need to introduce NoSql databases in the fture to handle the load.

The payment service may be doing too much. In the future we could implement a receipt service to offload some of this work

Future improvements

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

A new receipt service that retrives data from a cache. This should improvement performance.

We can offload the new receipt service to a new noSQl database where we read the receipt via the userID and the receiptID